July 2011 - Posts

In continuing my series of posts on errors, today’s error can occur when a user tries to create his or her SharePoint My Site for the first time.  When you click the My Content link to create the site, you might see an error like the one below.

My Site: There has been an error creating the personal site. Contact your site administrator for more information.

Not sure of what the issue was at first, I decided to check the ULS logs and saw a variety of errors like the ones below.

Failed to activate site-collection-scoped features for template 'global' in site collection 'http://mysitehost/my/corey_roth'.

Failed to activate site features when provisioning site at url "http://mysitehost/my/corey_roth" with site definition "(null)".

Failed to apply global template to site "/my/corey_roth", error: 0x1ccda910

Cannot create site: http://mysitehost/my/corey_roth for owner "domain\corey.roth", Error: <nativehr>0x80070003</nativehr><nativestack></nativestack>, 0x1ccda950

The answer really wasn’t apparent given those errors so I decided to go back and check all my settings.  The My Site configuration settings were fine in my User Profile Service Application.  I then took a look at the managed paths for the site collection.  After examining further, I discovered that the managed path  for /my had been set up with an explicit inclusion instead of a wildcard inclusion.  Once I changed it to wildcard inclusion, I could create a My Site without issue.

Sometimes, it is good to get back to the basics.  This may seem like a simple task for many of you, but there are many that don’t fully understand what is behind setting up a file share and the required permissions.  Years ago, I always thought I understood how this worked.  However, after taking some formal Windows Server training about 10 years ago, I discovered there was more to it than I thought. 

You probably already know how to get started when it comes to folder sharing.  You right click on the folder and go to properties.  You can also start by clicking on Share with.  When it comes to permissions of a file share, the ability of a user to access it depends on the combined permissions of two places.  The first is the Sharing tab.  This represents who can actually open the share when trying to connect to it over the network.  The second is the Security tab which represents the NTFS permissions on the underlying file system.  Think of this as being the same as the user being on that server locally and trying to open that folder and read / write files to it.  When a user attempts to read or write a file to the share over the network, the user’s permissions on both the Sharing and Security tab are combined and evaluated.  The most restrictive permission wins.  We’ll talk about that what that means more here in a bit.

Let’s set up a new file share.  Windows Server 2008 revamped some of these screens a bit, but they are pretty similar in previous versions of Windows.  Let’s start with the Security tab.  When you first start out, you’ll get a screen like this.


Your permissions may vary some on your system, but the above is pretty typical of what you will get on a new folder.  Note, that I have the Users group highlighted.  This is all Users of that particular domain.  By default, this group has the following permissions: Read & execute, List folder contents, and Read permissions.  What’s the difference between Read & execute compared to Read?  It’s the ability to launch executable files as the name implies.  Any time you want to grant a group of users the ability to read files in a folder, you will use these three permissions typically.  If you want to allow the user to write to files, you will want to grant the Write permission.  Lastly, if you want to grant permission to delete files also grant the Modify permission.  In all the above cases, you would be selecting the checkboxes in the Allow column.  Here is what your permissions might look like if you added a new group called Executives and they had Modify access.


Lastly, if you want the user or group to be able to do anything to the folder, grant them Full control access.  There are also even more granular permissions if you click the Advanced button but you typically will not need those.

Wondering about the Deny checkboxes?  These should only be used in extreme situations as they override all other permissions.  What this means is that if a user is a member of a group that has permission to the share but also is in another group with the Deny checkbox, then that user will not have that privilege.  I’m not a security expert, but I seem to remember there being a best practice stating that you want to avoid using Deny if at all possible.  Here is an example of where Everyone was granted access to the folder but the user Joy Williams is denied on all permissions.  That means that Joy will not be able to access the files in this share.


Keep in mind that in SharePoint, the Search indexer respects these permissions and results will be security trimmed based on the NTFS permissions.  Therefore if I index this share, Joy will not see search results from it.  For more information on setting up SharePoint to index file shares, see this post.

At this point, we’ve covered what you need to do to set permissions on the underlying file system using the Security tab.  Any user logged directly onto the server can open this folder and verify that they can read / write files based on the permissions you set.  This is a good way to test when users report issues accessing the file share since it eliminates any permissions issues caused by what you have set on the Sharing tab.

To make the folder visible on the network, you now need to go to the Sharing tab.


Click the Share button and you will be able to select with whom you want to share the folder.  Yours will probably have similar groups and users depending on who originally created the folder.


In the drop down list, you can select Everyone or browse for specific people and groups.  In this case, I am going to add Everyone and our Executives group.


I granted Everyone Read access and Executives have Read / Write access.  When I click Share the file will now be shared using the same name as the folder (by default).


This gives you the path to the file share.  In my case, it’s \\sp2010\MyFileShare.  If you don’t like the name it chose, you can click on the Advanced Sharing button which gives you some more options.  At this point, your share is ready to go using the path you see.  With my Share, members of the Executives group will be able to modify files and everyone else will just be able to read them.

Now what happens if the permissions between the Sharing tab and the Security tab don’t match?  For example, the user has Read permission on the Sharing tab and Write permission on the Security tab.  If you remember from earlier, I said that the most restrictive permission applies.  Let’s take a look at a few examples in the table below.

Sharing Tab Security Tab Notes
Read Read User can read files using the share and local file system
Read / Write Read User can read files using the share and local file system
Read Write User can read files using the share and write files using the local file system
None Write User can’t access the file share at all but can write files using the local file system
Read / Write Write User can write files using the share and local file system
Read / Write Read + Deny Write User can read files using the share and local file system but cannot write files

Hopefully this table clears things up as far as permissions go.  Now what if your users get an error trying to use the file share?  First determine where the error occurs.  Can the user actually open the file share folder?  If not, they will probably get an Access is Denied error.  This tells you that the issue lies in the Sharing tab.  If they can open the file share folder, but can’t open a file or perhaps write to it, then you know you have an issue with what is on the Security tab.

This may seem pretty basic to some of you, but I think it will serve as a handy reference to people that have never set up a file share before.

I’m of the belief that the more information on errors I can put out there, the better we are all off.  There is nothing more frustrating than searching for the solution for an error on the Internet and not getting any usable results.  I recently configured Metalogix StoragePoint in an environment and after configuring it with the UNC paths of my file shares, I received the following error when trying to upload a file.

The URL 'filename’ is invalid.  It may refer to a nonexistent file or folder, or refer to a valid file or folder that is not in the current Web.

I suspected this was a permissions issue so I went to my ULS logs to find the issue.  I had to check both WFEs to find the errors.  I soon saw errors like the one below.

Error encountered in EndPoint.ProviderStoreBinary.BlobSave(Adapter), Folder:  FileName:.  Error is Access to the path '\\fileserver\RBSCache\2011\04\14' is denied.

This confirmed my suspicion so I corrected the permissions issue on the file share.  I tried to upload a file again and I still got the same URL is invalid error as before.  After check the logs again, I found a new error.

Error encountered in Profile.ProviderStoreBinary.General.  Error is The INSERT permission was denied on the object 'MigrateQueue', database 'StoragePoint', schema 'dbo'.

I knew this meant that my application pool account was lacking permissions in the StoragePoint database.  I checked another server to see what permissions were assigned to the account.  It turned out to be db_datareader and db_datawriter.  When I went back to the server in question, I noticed that the db_datawriter role was missing.  I granted the access and tried the upload again.  Everything now worked smoothly and I could upload and view files as desired.

During the Office 365 beta, I wrote a post about how to create a public facing web site with SharePoint Online.  This gives you a simple site that you can then begin to customize to your needs.  However, many people have said they found it lacking.  The site actions menu particularly frustrates people. However it’s easy to get around by simply going to the page /_layouts/settings.aspx.

I’m currently working on a Search talk with SharePoint Online for SharePoint Conference 2011 (#SPC11) and I got to thinking last night about how search works with a public facing web site.  The answer is, out-of-the-box, it doesn’t.  There is no search box on the home page nor is there a search center.  This post will teach you how to add search functionality but it won’t cover any of the branding aspects.  Creating a Search Center is relatively easy, just click on the Member Login link and then click All Site Content.  From here we can click the Create button to create our search center.


From the list you see above, Basic Search Center is our only option.  You can likely get the Enterprise Search Center template listed as well by activating the Publishing Infrastructure feature on the site.  However, we’ll just use a Basic Search Center though as it will suit our needs.  With on-premises solutions, I typically give my search centers a URL of /search.  However, for some reason SharePoint Online doesn’t allow it in my environment and I get the following error.

“Search” cannot be used as a site name.  Site names cannot contain certain reserved words and cannot begin with an underscore.  Please enter a different name.


I’m not sure if this is specific to my environment or not.  On the private site collection site, I have a search center at /search and it works fine.  Maybe that’s the issue, I don’t know.  Any how, to resolve it I just went with my backup URL of /SearchCenter and it worked fine.  After you create the site, you should have a site that looks like the one below.  Again it won’t have the master page or the styling as the rest of your site.  That’s up to you to customize later.


Let’s try out a query.  I’ll search for the term “Home”.


Look!  We get results!  It works!  Oh wait, after further examination, it gives me results for both my public facing and private site collection.  You might be thinking that’s bad, but in reality it’s working exactly as intended.  Search returns all results for your tenant that you have access to.  Since I was logged in, I get results from both sites.  What if I am not logged in though does search still work?  The answer is yes.  I opened a new browser windows with Google Chrome’s Incognito feature to force myself to sign out and here is what we get.


As you can see it now only shows results from the public facing web site.  Notice the Sign In link at the top right.  The beauty of talking about SharePoint Online though is that I can actually provide links to the site and you can try it yourself.  Execute the above query yourself by clicking here.  That link may not be good forever.  It should work though as long as I haven’t torn down the site, let my account expire, or used all of my resources.

What if we want to truly separate out the Search Results?  For example, you want your users to be able to be logged in but still only see the content from the public facing web site.  We can do that with a scope.  In SharePoint Online, scopes must be created at the Site Collection level.  Again go to /_layouts/settings.aspx and then click on the Search Scopes link.  Here, click on the New Scope link and give your scope a name.  In my case, I chose the name Public.  You may consider changing some of these other settings here later, but for now, I went with the default.  After you create it, you need to add a scope rule.  For Scope Rule Type, choose Web Address.  For Web Address, choose Domain or subdomain and then enter the domain of your site (minus the http://).  In my case, I entered dotnetmafia-web.sharepoint.com.  Lastly, for the Behavior radio button choose Require.  Here is what the screen looks like.


After you create the scope, you have to wait for a scope update.  Unfortunately, this can take a while (as shown below) and there isn’t a button for you to click to force the update to occur now like with on-premises SharePoint.


Once it occurs, try out a simple query using the keyword syntax on our existing search center.  I wrote a post on useful keywords to use in search a while back that describes the use of the Scope keyword as well as others.  I issued the following query.  Try it out for yourself.

home Scope:”Public”


Now that works great.  Obviously, we don’t want our users to have to type the scope in themselves though.  What we’ll do is set the scope property on the CoreResultsWebPart of the results.aspx page.  This will force all queries in that search center to use that scope and give us the results we want.  Edit the page, and then edit the CoreResultsWebPart.  Under Location Properties, type the name of your scope in the Scope box. 


When you are finished, click Ok, and then save your page.  When you are done, issue a query again without the Scope keyword and you should get the desired results. 


Like before, you can try the above query out yourself on my SharePoint Online site.  You now have a working search.  However, I wanted to point out one more potential issue.  On your Site Settings page, click on the Search Settings link.  Make sure it has the correct URL to your search center on the public facing site.  I have seen issues before where it was pointing to the private site collection.


At this point, you may want to customize the way your search center looks by applying a custom master page and what not.  It’s also up to you on how you want to get your users to the search center.  You can add the standard Search Box delegate control to your master page if you like.  You can also just provide a simple link to Search as well.  I’ll leave those items to the branding experts (I’m definitely not one of them :) ).  The links to my SharePoint Online site should work for a while and I’ll update them later if necessary.

Sometimes when you try to run a SharePoint 2010 Management Shell (PowerShell), you might encounter the error below.

The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered.


Although, the answer is not obvious given the error message, the answer is quite simple.  You tried to run PowerShell with a user account that is not an administrator in SharePoint.  In this case, I had ran it with my personal account which is not an admin and does not have access to the underlying SharePoint databases.  Hopefully, you used a “setup” account when you created SharePoint.  Execute PowerShell with that account instead.  You can do this either by logging in as that user.  You can also hold down the Shift key and right click on the SharePoint 2010 Management Shell icon and choose the Run as different user menu item.


If you don’t have a setup account, things might be a bit trickier.  You can also resolve this by running it as the farm account, but you really want to try and avoid this.

My first Service Pack 1 (SP1) installation experience (since release) went fairly smoothly.  I mentioned one minor issue you will see already during the install if you have Visual Studio installed.  However, this issue next issue took me a bit longer to fix.  When I went to open the PowerPoint Service Application, I was greeted with an error. 

The given key was not present in the dictionary.


Thinking that was weird, I went and decided to delete my PowerPoint Web App Service Application and recreate it.  The new one worked fine but I was still having an issue.  When I tried to view a PowerPoint document in the browser, the document would never open and my CPU would spike to 100%.  I immediately remembered this issue because it occurs when you run Office Web Apps on a domain controller.  You have to run the following script to allow it to work.

Get-SPPowerPointServiceApplication | Set-SPPowerPointServiceApplication -EnableSandboxedViewing $false
Get-SPPowerPointServiceApplication | Set-SPPowerPointServiceApplication -EnableSandboxedEditing $false

I’m not sure why my original PowerPoint Web App Service Application wouldn’t work, but it you encounter this issue, try recreating it and then make sure you run the PowerShell script if you are running on a domain controller.

When you are installing SharePoint 2010 Service Pack 1 (SP1), you might encounter the following error multiple times during the installation.

An unhandled exception (‘System.Security.Cryptography.CryptographicException’) occurred in OWSTIMER.EXE [3004].


This has been known to occur just because you have Visual Studio 2010 installed.  You’ve probably seen it in the past with day-to-day operation of your SharePoint environment.  I encountered this issue before and it has never seemed to prove to be an issue.  Just click the No button and let the installer finish.  You have nothing to worry about (yet) and your upgrade should proceed just fine.  It will likely pop up multiple times throughout the installation process.

Today’s post is just a quick tip on something you might want to consider after migrating to SharePoint 2010.  The Search Center site template differs a bit from what used to be there with SharePoint 2007.  New web parts exists for things like refinement and people search.  Sure you can always add these existing web parts to your existing search center, but I find it’s really just easier to delete the site and recreate it with the new template.  This is especially the case if you are adding FAST Search for SharePoint.  If you stick with your old site, you won’t have these new features unless you add them yourself. 

The caveat to add to this is that if you have done extensive customizations to your existing search center, you will need to redo these customizations.  There is a chance that your existing customizations might not even work any way.  This includes changes such as the columns in the result set or modifying the XSLT of the CoreResultsWebPart.  Anyhow, if you do a migration and you find that your search center doesn’t have all the new features you have heard about, create a new one.  Note, you can always create a new search center on a different URL and then change your site collection’s search center URL from the Search Settings page.