MyDocuments directory missing from SharePoint on Windows 7

It's fairly common practice for organizations to map its users' MyDocuments directory to a network (fileshare) location to facilitate back-up. The company laptop I received was no exception, but when I tried to download a document from SharePoint - the was no trace of MyDocuments anywhere on my machine from the file navigation dialog within SharePoint. Similarly, if I selected the 'Open in Explorer' command from the Actions dropdown - no MyDocuments. As it turns out, the network drive that MyDocuments points to is not index-able and consequently SharePoint does not acknowledge it.
When I deleted the network drive as a location and tried to add it back in, I got the following error:

This network location can’t be included because it is not indexed.

The network location also indicates a status of 'Unsupported' within the Documents Library Locations. Moreover, I can't seem to recover my original 'MyDocuments' location and instead had to create a new folder under my Users profile directory and set that as my default save location. SharePoint has no problem recognizing the new location (since it's index-able).
Here's a smattering of troubleshooting techniques I encountered for reference.



Posted on 7/13/2010 10:44:00 AM by sterlingt

Permalink | Comments (0) | Post RSSRSS comment feed |

Categories: MOSS 2007 | SharePoint 2007 | WSS 3.0 | Windows 7

Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

"June 'Black Tuesday' patch causes SharePoint woes"

Posted on 6/17/2010 12:11:00 PM by sterlingt

Permalink | Comments (0) | Post RSSRSS comment feed |

Categories: MOSS 2007 | SharePoint 2007 | WSS 3.0

Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Today's - Um....wuh?!


Trying to use the SharePoint List web service (List.asmx) AddAttachment method (http://msdn.microsoft.com/en-us/library/lists.lists.addattachment%28office.12%29.aspx) to add an attachment to a document library item? And seeing a cryptic 'Value does not fall within the expected range' exception? Well, APPARENTLY - this method doesn't work on document libraries (or form libraries): http://social.msdn.microsoft.com/Forums/en-US/sharepointdevelopment/thread/68db70bc-94b1-4dfb-b33e-e42341807583.

Um...wuh?! Yea. I got around it by using the Copy web service's (Copy.asmx) CopyIntoItems method (http://stackoverflow.com/questions/987581/how-do-you-use-the-copyintoitems-method-of-the-sharepoint-copy-web-service). Fortunately I'm creating a new attachment list item, rather than adding an attachment to an existing list item - not sure how to achieve that remotely.

'Scuse me while I go practice my speech to clients on why they should upgrade to SharePoint 2010 and its lovely Client Object Model.

Posted on 6/17/2010 8:22:00 AM by sterlingt

Permalink | Comments (0) | Post RSSRSS comment feed |

Categories: MOSS 2007 | SharePoint 2007 | WSS 3.0

Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Installing SharePoint 2007/2010 with Active Directory 2000

The first order of business should be upgrading your domain controller since apparently SharePoint 2007+ doesn't play nice with this legacy version of AD (http://msmvps.com/blogs/obts/archive/2006/09/27/143844.aspx). If that's not an option before your install of SharePoint, you'll need to do the following in order to use any domain accounts for the various SharePoint service accounts (required if you're building a multi-server farm).

Disable domain digital encryption on all SharePoint servers:
  1. Navigate to Administrative Tools > Local Security Policy
  2. Expand 'Local Polices'
  3. Select 'Security Options'
  4. Navigate to the 'Domain member: Digitally encrypt or sign secure channel data (always)' item within the main display pane and right click > properties - disable.
  5. Repeat the previous step for the 'Domain member: Digitally encrypt secure channel data (when possible)' and 'Domain member: Digitally sign secure channel data (when possible)' items.
  6. RESTART ALL SERVERS (This change will not take effect until the relevant server is restarted.
This should alleviate the problems with locating domain users based on their 'friendly' Netbios name rather than SID's. Without this change you will receive the following error when trying to provide domain account credentials for the farm service account while running the SharePoint configuration wizard:

The username is invalid. The account must be a valid domain account.

In addition, when trying to add a domain account login to the Sql Server instance you will receive the following error:

Create failed for login…Windows NT user or group domain\username not found. Check the name again.

Couldn't find any documentation on the 'net regarding this obscure scenario, so I wanted to share my insight. Disclaimer: I'm not a sys-admin so I cannot comment on the security compromises that this change might introduce.

Posted on 5/12/2010 8:55:00 AM by sterlingt

Permalink | Comments (2) | Post RSSRSS comment feed |

Categories: MOSS 2007 | SharePoint 2007 | WSS 3.0

Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

"Serious XSS flaw haunts Microsoft SharePoint"

Posted on 5/4/2010 4:39:00 AM by sterlingt

Permalink | Comments (0) | Post RSSRSS comment feed |

Categories: MOSS 2007 | SharePoint 2007 | SharePoint 2007 Features | WSS 3.0

Tags:

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5