Removing a Managed Account from SharePoint 2010

Hello to my two regular readers and people who accidentally clicked this link from twitter! My apologies that it has been so long since my last post.

This morning I found a peculiar little quirk of SharePoint 2010 today when trying to make changes to the Managed Accounts on one of my farms.

This error was coming up whenever I tried to access the "Managed Accounts" section of security under Central Administration.  Obviously this caused a problem as I could not add / remove any service accounts, and one of them was corrupted.  How did I manage to corrupt a service account?  Thats a story for another time.

So I figured the easiest way to get rid of this would be to familiarize myself with the SharePoint PowerShell Cmdlets.

First off I loaded the appropriate PowerShell snapin via "Add-PSSnapin Microsoft.SharePoint.Powershell"

By using the "Get-Command -Noun "SP*" I was able to get a full list of SharePoint commands, and pretty much right where I expected it was "Get-SPManagedAccount"

By using this command I was able to output a list of my Managed Accounts :

Simple PowerShell logic dictated that the appropriate commands were most likely "New-SPManagedAccount", "Set-SPManagedAccount" and "Remove-SPManagedAccount".  


Fairly quickly I was able to remove the offending ManagedAccount and restore functionality to the "Managed Accounts" section of Central Administration.

Managed Accounts

For those not familiar with PowerShell this is all very simple and easy to accomplish.  If you are ever in doubt on how to use a PowerShell command just type in "Get-Help CommandName -full" and you will have a whole heap of information to help you out.


The user does not exist or is not unique

Many times in the last couple of years I have come across the message "The user does not exist or is not unique."  It is usually on its own, with no other error messages or clues to deciphering its cryptic text.  Generally I have had only limited success in getting past this error, usually getting around it via chance or a rebuild / restore. 

Today when trying to move a Site Collection from a Dev to a Production server we came across this message, it was occuring on just about every stsadm command I ran.  To make matters worse in Central Administration I could not even select the Site Collection.  Obviously at this point a rebuild / restore (my usual methods for dealing with this kind of thing) would not be very helpful being a brand new server, and I was trying to restore a backup anyway.

Even using stsadm I could not set myself as the Site Collection Owner. 

C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12BIN>stsadm -o siteowner  -url -ownerlogin domainadmin

The user does not exist or is not unique.

It turns out that the cause of this was not something unique to production server like I would expect, it was something from the development server that I definitely did not expect.  In this case the Site Collection had been restricted to a specific Active Directory Organizational Unit.  I would not have expected this to be done on a production server, let alone on a development server, and did not go looking for it. 

Even if I had gone looking for it, where would I find it?  It can be found with the following command :

stsadm -o getsiteuseraccountdirectorypath

The "GetSiteUserAccountDirectoryPath" command allows you to lock down a Site Collection to only add new members that are inside the Organization Unit specified when running the command. 

What was fairly unique about this scenario was that in this case, as almost every time I ran any command that referenced the Site Collection I would receive "the user does not exist or is not unique".

To check to see if this property was even set, I ran the command as the Application Pool account for the Web Application. 

C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12BIN>runas /noprofile /user:DOMAINapp-pool-acct cmd
Enter the password for DOMAINapp-pool-acct:
Attempting to start cmd as user "DOMAINapp-pool-acct" …

Using this user I was able to successfully confirm that the Site Collection was definitely locked down to a specific OU, which did not even exist in this environment :

C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12BIN>stsadm -o getsiteuseraccountdirectorypath -url


I was then able to unlock the Site Collection from the OU by issuing the following command :

C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12BIN>stsadm -o setsiteuseraccountdirectorypath -url -path ""

Operation completed successfully.

A quick retry of the previous operation was successful and I could once again make myself a Site Collection Administrator. 

C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12BIN>stsadm -o siteowner  -url -ownerlogin DOMAINadmin

Operation completed successfully.

At this point the Operation completed successfully message was a very welcome message. 

While I do not expect that this will be the cause for every instance of this error message, it is a helpful marker that tends to indicate when this error is occuring the Site Collection is unable to find a user object in Active Directory.  If this error occurs I strong recommend looking at anything that may help or hinder access to Active Directory. 

It is also possible this issue could have been resolved by the peoplepicker-serviceaccountdirectorypaths property, however I did not have a chance to try this out.  For more information on that one :

Presenting this month at two user groups.

Just a quick update as I will be presenting this month at two usergroups.

On Tuesday 10th March I will be presenting on System Center virtual Machine Manager 2008 at Brisbane Infrastructure Group

Session #2, Hosting and Self Provision of Virtual Machines with SCVMM w/ Mark Rhodes

Hosting virtualized servers is easy, especially with tools like SCVMM 2008, but giving tools to clients to manage those servers is more difficult.  Mark will demonstrate what his production SCVMM 2008 self-service portal and what you can do with it.  In addition to this he will also about some of the functions he has used since implementing SCVMM 2008 (i.e. P2V, V2V, Archiving of old servers, Managing Checkpoints)

 Mark will also share some of those ?notes from the field? he encountered that may not be immediately obvious during his deployment.

This one is on at 5:30pm at Microsoft's Brisbane office.I will also be presenting at the Brisbane Sharepoint Users Group on the 18th.  I will be talking about hosting, as yet I do not have an abstract on this, but most likely I will cover the benefits of hosting, basic hosting technology and the future of hosted services.This one is at 12:30 at Microsoft's Brisbane Office.

Content Deployment Error – There is no web named "".

Content deployment seems to be one of those topics that a lot of people tend to avoid, this is most likely because it has a whole host of nuances and subtleties that can make it seem buggy or unusable.

In the spirit of documenting the little quirks of content deployment, here is one I encountered just this week. 

The Execute method of job definition Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJobDefinition (ID d3d7ac13-f785-4f03-8a73-88505cf6ec7b) threw an exception. More information is included below.

There is no Web named "".

I coaxed this error out from a failing content deployment job after chasing wild geese in the form of two error messages :

Publishing: Content deployment job failed. Error: 'System.ArgumentOutOfRangeException: The specified indexer value for this collection could not be found or is not unique.
Parameter name: jobId


The Execute method of job definition Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJobDefinition (ID ac28b255-0933-4ba0-9458-20bf97f6fcf9) threw an exception. More information is included below.

The specified indexer value for this collection could not be found or is not unique.
Parameter name: jobId

Getting past those two errors was simply restarting the WSS Search and Office Search services via Services, and then starting them up again via Stsadm.  Immediately after this upon the next content deployment push I saw the initial error message with "There is no web named """.

The cause of the message was the transaction log on the database running out of space.  I have seem this happen before if the content deployment push is a large one, in one case we saw the transaction log blow out to over 50 gigabytes in less than an hour.

In this particular case it was because the transaction log was set to autogrow with a maximum size of 6 gigabytes.  As soon as the transaction log was truncated via a SQL backup there was space available and the content deployment could continue!

For sites using Content Deployment regularly I would recommend plenty of disk space, an unlimited transaction log size, and regular incremental backups to ensure the logs are truncated regularly.

Why are my SharePoint Audit Logs missing the MachineName and MachineIP data?

Audit Log Reporting seems to be one of those topics within SharePoint that is still a little misunderstood.  I have blogged on it before here, and suggest that if you are not familiar with Audit Logs that you view that post quickly before reading on.  There is also an overview which can be read here on the site.

I received a question about Audit Log Reporting from one of the readers of my blog a few months ago, and since then it hasn't been the first time I've heard it :

I read your blog about SharePoint Audit Log Report. I'm trying to get a report but I cannot get the "Machine Name" and "Machine IP" data. Can you help me? Is there any settings that I'm missing?

My answer was that there were no settings missing, and unfortunately the data missing is by design. 

Here is a row taken straight from the Audit table :

Site Id Item Id Item Type User Id Machine Name Machine IP Document Location Location Type Occurred (GMT) Event Custom Event Name Event Source Source Name Event Data
ed91340f-e335-45d2-82f3-c6521eb23fc0 59af845e-b604-436e-9c08-0a948a27d996 Document NT AUTHORITYlocal service _catalogs/masterpage/Editing Menu/CustomSiteAction.xml

As you can see the MachineName and MachineIP values are mysteriously null, in fact querying the table for a row where they were not null returns zero results, they are never used. Unfortunately the reason in this case is to view KB939246, which has the following as a cause : The values in the MachineIP column and in the MachineName column appear as NULL because of privacy concerns. By design, Windows SharePoint Services 3.0 works in this manner.

This feature is not going to be reporting MachineName or MachineIP of actions in the audit log any time soon, it is a bit of a shame because I can imagine some occasions where this could be useful.  Keep in mind that your IIS logs will still contain all the IP information, and if you have a timestamp you should have no problem tracing that request back to a particular IP.  Unless you have your site set to be edited by anonymous users, the UserID field is going to be far more valuable when utilizing these reports, however you may need to perform a join to the userinfo before you will get anything particularly relevant out of it, i.e.

SELECT     UserInfo.tp_Login AS UserLogin, UserInfo.tp_Title AS UserTitle, AuditData.SiteId, AuditData.ItemId, AuditData.ItemType, AuditData.DocLocation,
                      AuditData.Occurred, AuditData.Event, AuditData.EventName, AuditData.EventSource, AuditData.SourceName, AuditData.EventData
FROM         AuditData
INNER JOIN UserInfo ON AuditData.UserId = UserInfo.tp_ID

I would not be surprised if the functionality to turn back on the MachineIP and MachineName reporting could be enabled by flicking a switch in the registry or database, but as yet I have had no luck finding it.  Maybe someone else out there will, good luck!

December Cumulative Updates for SharePoint re-released.

If you have tried to install the recently released December Cumulative Update for SharePoint you may have noticed that the original release actually fails during the post-installation configuration.  Jeremy Thake came across the same issue at and has more detail on it here . I had difficulty installing this myself, but was able to get around the errors that occur by taking similar steps to Jeremy.  

 Fortunately the SharePoint Team noticed this fairly quickly and have released an updated version of December Cumulative Updates that no longer causes this issue.The revised version can be downloaded from the updated links on the original SharePoint team blog post :, and now there is a small comment on the page reflecting the investigation and update to the installer. 

A comment from myself on this particular update, finally it is actually cumulative!  This update can be applied from SharePoint SP1 upwards, however, as always, just because hotfixes are released does not mean they need to be installed!  Gauge the need to install them carefully against the problems they resolve.  For most installations SP1 + Infrastructure Updates will be more than sufficient, with the exception of any security updates that have or may be released in the future, i.e.  MS08-077.

Revisited – Content Deployment error? How to find those checked out items within Sharepoint

A month or so ago I put up a post about how to find checked out items within a Sharepoint site.  This particular error tends to bring up problems with Content Deployment, as CD cannot occur if there are any items checked out.

Unfortunately there is no inbuilt method to find these items for an Administrator, the only way within the standard Sharepoint interface if that on the Site Actions menu, each user can check if there are any items still checked out and quickly check them back in.  Training users to do this can be problematic however, and sometimes it is just easier to point them at the items that are still checked out.

I had a query to do this, but one of the readers has suggested a much better query than my own for finding these items :

SELECT AllUserData.tp_DirName, 'http://SiteName/&#039; + AllUserData.tp_DirName, AllUserData.tp_LeafName,
case when AllUserData.tp_ContentType = 'Item'
then 'http://SiteName/&#039; + AllUserData.tp_DirName + '/DispForm.aspx?ID=' + AllUserData.tp_LeafName
else 'http://SiteName/&#039; + AllUserData.tp_DirName + '/' + AllUserData.tp_LeafName
end as Link,AllUserData.tp_ContentType, AllUserData.nvarchar1, AllUserData.nvarchar2, AllUserData.tp_ModerationStatus, AllUserData.tp_DeleteTransactionId, AllUserData.tp_IsCurrent
FROM AllUserData AllUserData
WHERE (AllUserData.tp_ModerationStatus=2)
AND (AllUserData.tp_DeleteTransactionId=0x0)
AND (AllUserData.tp_IsCurrent=1)
ORDER BY AllUserData.tp_DirName, AllUserData.tp_LeafName

Just replace the http://SiteName/ with the url to your Site, and use this on the database of your Web Application and you are good to go. Thank you very much to for supplying this great query.

Content Deployment error? How to find those checked out items within Sharepoint

If you have content deployment running you have probably seen this error before :

10/30/2008 1:01 AM You cannot perform this action on a checked out document. at Microsoft.SharePoint.SPListItem.SetRequiredInfoForUpdateItem(Boolean bDocLib, Boolean bAdd, Boolean bMigrate) at Microsoft.SharePoint.SPListItem.PrepareItemForUpdate(Guid newGuidOnAdd, Boolean bMigration, Boolean& bAdd, Boolean& bPublish, Object& objAttachmentNames, Object& objAttachmentContents, Int32& parentFolderId) at Microsoft.SharePoint.Deployment.ListItemSerializer.AddOrUpdateDoclibItemVersion(SerializationInfoHelper infoHelper, SPListItem& listItem, SPWeb web, Guid newId, String& listItemServerRelativeUrl, Boolean bIsPublish, Boolean exists, String version, Boolean isFirstVersion, Boolean isLastVersion, StreamingContext context, ISurrogateSelector selector, ImportObjectManager objectManager) at Microsoft.SharePoint.Deployment.ListItemVersionSerializer.AddListItemVersion(SPWeb web, SPListItem listItem, Guid newId, Boolean editHistory, Boolean existsInDb, Boolean isFirst, Boolean isLast, Boolean isDocLib, StreamingContext context, XmlElement listItemData, SPImportSettings settings, ImportObjectManager objectManager, SerializationInfoHelper listItemInfoHelper, String& listItemServerRelativeUrl, ISurrogateSelector selector) at Microsoft.SharePoint.Deployment.ListItemSerializer.UpdateListItemVersionData(SerializationInfoHelper infoHelper, SPWeb web, SPListItem& listItem, Guid newId, Boolean existsInDb, Boolean isDocLib, String& listItemServerRelativeUrl, StreamingContext context, SPImportSettings settings, ISurrogateSelector selector) at Microsoft.SharePoint.Deployment.ListItemSerializer.SetObjectData(Object obj, SerializationInfo info, StreamingContext context, ISurrogateSelector selector) at Microsoft.SharePoint.Deployment.XmlFormatter.ParseObject(Type objectType, Boolean isChildObject) at Microsoft.SharePoint.Deployment.XmlFormatter.DeserializeObject(Type objectType, Boolean isChildObject, DeploymentObject envelope) at Microsoft.SharePoint.Deployment.XmlFormatter.Deserialize(Stream serializationStream) at Microsoft.SharePoint.Deployment.ObjectSerializer.Deserialize(Stream serializationStream) at Microsoft.SharePoint.Deployment.ImportObjectManager.ProcessObject(XmlReader xmlReader) at Microsoft.SharePoint.Deployment.SPImport.DeserializeObjects() at Microsoft.SharePoint.Deployment.SPImport.Run()
10/30/2008 1:01 AM Content deployment job 'Remote import job for job with sourceID = bc232239-4545-4050-a8fe-85a5e4b8b112' failed.The exception thrown was 'Microsoft.SharePoint.SPException' : 'You cannot perform this action on a checked out document.'

 Pretty obviously this error is caused by a checked out document, which can be a real pain to find if you have a big site with multiple authors.  The following query when run on your content database (run this on your authoring database, not your production one!) will find all checked out items and tell you roughly where to look, which filename, and the user responsible.

SELECT tp_dirname, tp_leafName, userinfo.tp_title, userinfo.tp_email
FROM AllUserData
NNER JOIN AllLists on AllUserData.tp_listid = AllLists.tp_id
INNER JOIN userinfo on alluserdata.tp_checkoutuserid = userinfo.tp_id
WHERE tp_checkoutUserId != ''
order by tp_dirname, tp_leafname

Increasing the maximum upload limit on a Sharepoint Site

A new colleague here asked me today how to configure WSS v3 for files larger than the default limit of 50mb today.  I asked him to quickly tap it into google as I figured there would be hundreds of posts out there on how to do it, but sadly almost all of them seem to be for WSS v2.

Fortunately most of the principles are still the same, except there are far less steps to do :

1.  Increase the Web Applications Upload limit.
2.  Increase the HTTP Timeout.
3.  Increase the Execution Timeout and MaxRequestLength in web.config

Typically step 1 should only be necessary on an Intranet environment, but steps 2 and 3 should only be necessary if you are on a slow connection, or getting timeout errors when attempting to upload large files.

The instructions for each step are below :

1.  Open Central Administration. Go to "Application Management", then "Web Application General Settings".  Ensure you are on the correct web application and modify the "Maximum Upload Size" field.

2.  Open IIS, find the appropriate website and open its properties.  The timeout setting is on the Website tab and in the connections setting under "Http Connection Timeout".  I'd probably consider adding 120 seconds per extra 50 mb, more or less depending on your connection.

3.  Edit C:Program FilesCommon FilesMicrosoft SharedWeb server extensions12TEMPLATELAYOUTSweb.config

From : 

  <location path="upload.aspx">
      <httpRuntime maxRequestLength="2097151" />

To : 

  <location path="upload.aspx">
      <httpRuntime maxRequestLength="2097151" executionTimeout="999999"/>

Edit the web.config in the home directory of the IIS Site of your web application.

From :

<httpRuntime maxRequestLength="51200" />

To :

<httpRuntime maxRequestLength="51200" executionTimeout="999999" />

Slipstreaming your Sharepoint installation, easy!

If you have been regularly installing Sharepoint farms you might notice that in the last 12 months there has been a large amount of time consuming hotfixes to deploy with each server installation of both WSS and MOSS.  With MOSS you've got all the WSS ones as well as the copious amount of MOSS hotfixes.

Here is the current patch path as recommended by the Microsoft Sharepoint Team :

1. Windows SharePoint Services 3.0 Service Pack 1
2. The 2007 Microsoft Office Servers Service Pack 1
3. The Windows SharePoint Services Infrastructure Update x86 x64
4. The Microsoft Office Servers Infrastructure Update x86 x64
5. KB 953397: Excel Server Security Update x86 x64
6. KB 955586: Document Lifecycle Workflow Update
7. August Cumulative Update for Windows SharePoint Services 3.0 (Global)
8. August Cumulative Update for Windows SharePoint Services 3.0 (Local)
9. August Cumulative Update for Microsoft Office Servers

Wow thats a few patches needed!  I started to get fairly jack of installing these before I was even installing 3 – 9, so heres a really brief and easy way to slipstream the install.

1. Download all of the above patches
2. Take a copy of the MOSS dvd.  Keep note of the path you copied this to.
3. One by one use the following syntax to pull out all of the information from the hotfixes :

hotfixname.exe /extract:<path to moss folder>x86updates /passive

This will extract all the files in the hotfix to your copy of the MOSS DVD x86update folder. 

Now when you run setup, you wont need to spend half an hour patching afterwards.  For WSS the same principle applies, except use the WSS patches only, and probably start with the WSS 3.0 SP1 installer.