Resolving a HTTP/1.1 200 OK Server: Microsoft-IIS/7.5 Error with a SharePoint 2010 Web Application

This error stopped me in my tracks for a couple of hours, while just editing IIS bindings and Alternate Access Mappings my site stopped responding entirely.

Instead of displaying a lovely site, my browser just displayed a blank error message.   Turning off Friendly Error messages I found the following error message displayed :

HTTP/1.1 200 OK Server: Microsoft-IIS/7.5 Date: Tue, 10 Aug 2010 03:19:45 GMT Connection: close

Unfortunately this error is not as helpful as you would think.  The only time I’ve seen similar errors with SharePoint were with 404 errors, usually because a Web Application existed, but a Site Collection did not.

I also noticed quite a few of these errors in the event log :

Unknown SQL Exception -1 occurred. Additional error information from SQL Server is included below.
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified)

Again this was not helpful, as I had other Web Applications on the same servers, which had no problem connecting at all!

Out of some desperation I decided to try detaching and reattaching the content database for the Web Application, and Voila!  The site came back online.   I do not have any idea why this was actually happening, however I’m putting it up here in case someone else comes across it.


Status Code 87 when trying to Validate Windows Server 2008 R2 Failover Cluster

Just came across this funky little error when trying to validate a cluster on Windows Server 2008 R2's Failover Cluster Manager.  In particular it comes up when attempting the "List All Disks" step.

"Clustering Validation check fails: Failed to prepare storage for testing on node ClusterNodeX Status 87"

Nothing really helpful shows up in the log files, and somewhat frustratingly only came across the solution by trial and error.  It seems that the tiny little boot partition at the start of the primary operating system disk (I think this is new with the Windows Build 6.1 Kernel [Windows Server 2008 R2]) does not have a drive letter assigned or mount point assigned.  Just assign a drive letter using diskmgmt.msc or diskpart for both nodes of your cluster and it will disappear and you will be able to validate.

There were other volumes that did not have a mountpoint or drive letter assigned, so I am assuming this error is specific to the primary disk.

Seems pretty silly, hope this is something that gets addressed by the upcoming Service Pack for Windows Server 2008 R2.


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 :

Installing CRM 4.0 on Microsoft SQL Server 2008

For anyone who has tried to install CRM 4.0 on a SQL Server 2008 installation you will probably know there are a few checks in the CRM installer that make this installation quite painful.  It took me a few hours of fiddling and going through the install logs carefully to fix the two issues that occurred.

Setup failed to validate specified Reporting Services Report Server.  Error: The operation you are attempting requires a secure connection (HTTPS)

This error is occuring because SQL Reporting Services on 2008 is expecting an SSL connection.  By editing %ProgramFiles%Microsoft SQL ServerMSRS10.MSCRMRPTReportingServicesReportServerrsreportserver.config and changing this line from <Add Key="SecureConnectionLevel" value="2"/> to <Add Key="SecureConnectionLevel" value="0"/> you will stop this requirement.  I do not know of any adverse effects of doing this, so it should be safe to leave in this state, otherwise you may find issues later on when using Reporting Services within CRM.

Check FullTextRunningValidator : Failure: Service msftesql was not found

This error is occuring because CRM 4.0 thinks it needs the SQL Full Text Search service to be installed at the time of installation, but SQL 2008 does away with this service entirely!  To install we need to trick CRM 4.0 into thinking that the service is available and running, we can do this by just hacking at the registry and renaming another service to be "msftesql".  It really does not matter which service you use for this, as long as it is another service that wont be missed in the mean time, as per a forum post I would recommend using the Filter Daemon Host Launcher (MSSQLFDLauncher).

All of the services can be found at HKLMSystemCurrentControlSetServices, just right click and rename to "msftesql". You may need to reboot before this takes effect and don't forget to start the service! Also remember to rename the service back to its original name after the install is completed, there should be no complications from doing this as long as you install the update rollups.

Both of these issues are also listed on this Microsoft article :, however the article is a little less than helpful as its solution is installing the CRM Update Rollups that fix the issues.  This turns into a chicken and egg problem as I cannot see any way to install the hotfixes prior to installing CRM, nor have I found how to slipstream the installs to include the update rollups as yet.

And lastly, do not forget to install CRM Update Rollup 5 which was recently released, this rollup contains all the previous updates which address a few of the issues that can be encountered when running CRM on SQL 2008.  Hopefully this posting will help a few people avoid the couple of hours it took me to work around these issues.

Error while publishing CRM 4.0 Workflow

I have seen this error three times now, the first time I made a recommendation to contact Microsoft Premier Support, the second time I worked it out, and this third time I decided it was worth blogging about.

The error is very simply when you attempt to publish a workflow you receive a rather unhelpful "The workflow cannot be published" such as the picture below.  This behavior seems to occur straight after applying an Update Rollup, however seems to occur far more frequently after Update Rollup 3 and 4.

Workflow Error

The following more helpful error is recorded in the Event Log :

Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 6/19/2009 10:53:10 AM
Event time (UTC): 6/19/2009 12:53:10 AM
Event ID: 63e4987779424d0b8eb93fca2566a7cf
Event sequence: 13175
Event occurrence: 6
Event detail code: 0
Application information:
    Application domain: /LM/W3SVC/1/ROOT-1-128897723456212507
    Trust level: Full
    Application Virtual Path: /
    Application Path: c:inetpubwwwroot
    Machine name: XXXXXXX
Process information:
    Process ID: 9116
    Process name: w3wp.exe
Exception information:
    Exception type: TargetInvocationException
    Exception message: Exception has been thrown by the target of an invocation.
Request information:
    Request URL: http://CRM/CRM/_grid/cmds/dlg_activate.aspx?iObjType=4703&iTotal=1&iIndex=0&iId={FC6EF8AE-96F6-427B-9F21-24E9A7E9E85B}
    Request path: /CRM/_grid/cmds/dlg_activate.aspx
    User host address:
    User: Username
    Is authenticated: True
    Authentication Type: Negotiate
    Thread account name: NT AUTHORITYNETWORK SERVICE
Thread information:
    Thread ID: 1
    Thread account name: NT AUTHORITYNETWORK SERVICE
    Is impersonating: False
    Stack trace:    at Microsoft.Crm.Application.Utility.Util.RaiseXMLError(Exception exception)
   at Microsoft.Crm.Dialogs.ActivateDialogPage.ConfigureForm()
   at Microsoft.Crm.Application.Controls.AppUIPage.OnPreRender(EventArgs e)
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

After much digging and poking I finally tried comparing the web.config file of the CRM server experiencing this error to another server which had not yet had an update rollup done, and immediately I noticed a major difference.  There were four lines missing from the AuthorizedTypes section of the config file!

Missing from Auth Types

 Immediately I took a backup of the existing web.config and then added those four lines in, Bingo!  Immediately I was able to publish workflows.  From a bit of research I did after finding this I was able to find out that this problem was thought to be resolved post Update Rollup 2, however judging from these results this is not the case.  Not so easy to find, but very easy to fix.  My suspicion is that the error will only show up when the web.config was previously modified after the initial installation of CRM, which would explain why we are seeing this semi-frequently on hosting environments, especially the ones with a large amount of customizations.

The four lines I applied into the web.config follow :

      <authorizedType Assembly="mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System"  TypeName="Void" Authorized="True"/>
      <authorizedType Assembly="mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System.Reflection"  TypeName="AssemblyFileVersionAttribute" Authorized="True"/>
      <authorizedType Assembly="mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System.Reflection"  TypeName="AssemblyVersionAttribute" Authorized="True"/>
      <authorizedType Assembly="mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System.Globalization" TypeName="CultureInfo" Authorized="True"/>

Troubleshooting CRM 4.0 System Jobs

I stumbled across something I'd never noticed before in CRM 4.0 today, I suppose in retrospect it is pretty obvious, but I thought I would mention it anyway.  It is pretty simply the ability to create a custom view that has error messages for your system jobs.

  1. Go to Settings
  2. Go to System Jobs
  3. Click on Advanced Find
  4. Click on Edit Columns
  5. Wait until this page populates, this can take a while
  6. Click Add Columns
  7. Tick "Error Code" and "Messages", and any other relevant fields if you like!
  8. Click "OK" to leave the Add Column View
  9. Click "OK" again to leave the Edit Columns View
  10. Click "Save As" and put in an appropriate name and click "OK"
  11. Exit the wizard
  12. Refresh your system jobs view
  13. Now in the views drop down your new view should be there

Now by using this view, you will be able to see the error code and the error message.  Very handy!

Error adding users to Microsoft Dynamics CRM 4.0.

Today I came across an issue with CRM 4.0 where one of our dedicated installations with its own Active Directory could not add users into CRM.Naturally, the error displayed inside CRM was a generic error message with no specific information of any helpful nature. 

The error from the Trace Logs was as follows :  

[2009-01-15 11:37:47.8] Process: w3wp |Organization:373c636e-eaf2-404d-bf10-979cb92e39d3 |Thread:    8 |Category: Platform |User: 2d9d9775-7b3b-4a62-bde2-aaee539c8aa5 |Level: Error | MessageProcessor.Execute
>MessageProcessor fail to process message 'Create' for 'systemuser'.
[2009-01-15 11:37:47.8] Process: w3wp |Organization:373c636e-eaf2-404d-bf10-979cb92e39d3 |Thread:    8 |Category: Exception |User: 2d9d9775-7b3b-4a62-bde2-aaee539c8aa5 |Level: Error | CrmException..ctor
 at CrmException..ctor(String message, Exception innerException, Int32 errorCode)
 at SoapExtensionExceptionHandlerBase.GetCrmException(Exception exception)
 at InProcessCrmService.Execute(Object request)
 at PlatformCommand.ExecuteInternal()
 at CreateCommand.Execute()
 at SystemUser.Create(Boolean performDuplicateCheck)
 at EntityProxy.CreateAndRetrieve(String columnSet, Boolean performDuplicateCheck)
 at AppForm.RaiseDataEvent(FormEventId eventId)
 at EndUserForm.Initialize(Entity entity)
 at CustomizableForm.Execute(Entity entity, String formType)
 at SystemUserDetailPage.ConfigureForm()
 at AppUIPage.OnPreRender(EventArgs e)
 at Control.PreRenderRecursiveInternal()
 at Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
 at Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
 at Page.ProcessRequest()
 at Page.ProcessRequest(HttpContext context)
 at biz_users_edit_aspx.ProcessRequest(HttpContext context)
 at CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
 at HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
 at ApplicationStepManager.ResumeSteps(Exception error)
 at HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData)
 at HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr)
 at HttpRuntime.ProcessRequestNoDemand(HttpWorkerRequest wr)
 at ISAPIRuntime.ProcessRequest(IntPtr ecb, Int32 iWRType)


>MSCRM Error Report:
Error: Exception has been thrown by the target of an invocation.
Error Message: Exception has been thrown by the target of an invocation.
Source File: Not available
Line Number: Not available
Request URL:{9CEDFF4E-82CA-DD11-82C1-00215E3F818C}
Stack Trace Info: [UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))]
[TargetInvocationException: Exception has been thrown by the target of an invocation.]
   at System.DirectoryServices.DirectoryEntry.Invoke(String methodName, Object[] args)
   at Microsoft.Crm.BusinessEntities.SecurityUtils.AddPrincipalToGroup(Guid principalId, Guid groupId)
   at Microsoft.Crm.BusinessEntities.SecurityLibrary.AddPrincipalToGroup(Guid principalId, Guid groupId)
   at Microsoft.Crm.ObjectModel.SystemUserServiceInternal`1.ManageGroupsHelper(Guid activeDirectoryGuid, Boolean remove, ExecutionContext context)
   at Microsoft.Crm.ObjectModel.SystemUserServiceInternal`1.AddPrincipalToGroups(Guid activeDirectoryGuid, ExecutionContext context)
   at Microsoft.Crm.ObjectModel.SystemUserServiceInternal`1.CreateInternal(Guid organizationId, IBusinessEntity systemuser, ExecutionContext context)
   at Microsoft.Crm.ObjectModel.SystemUserServiceInternal`1.Create(IBusinessEntity systemuser, ExecutionContext context)

[TargetInvocationException: Exception has been thrown by the target of an invocation.]
   at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
   at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Web.Services.Protocols.LogicalMethodInfo.Invoke(Object target, Object[] values)
   at Microsoft.Crm.Extensibility.InternalOperationPlugin.Execute(IPluginExecutionContext context)
   at Microsoft.Crm.Extensibility.PluginStep.Execute(PipelineExecutionContext context)
   at Microsoft.Crm.Extensibility.Pipeline.Execute(PipelineExecutionContext context)
   at Microsoft.Crm.Extensibility.MessageProcessor.Execute(PipelineExecutionContext context)
   at Microsoft.Crm.Extensibility.InternalMessageDispatcher.Execute(PipelineExecutionContext context)
   at Microsoft.Crm.Extensibility.ExternalMessageDispatcher.Execute(String messageName, Int32 primaryObjectTypeCode, Int32 secondaryObjectTypeCode, PropertyBag fields, CorrelationToken correlationToken, CallerOriginToken originToken, UserAuth userAuth, Guid callerId)
   at Microsoft.Crm.Sdk.RequestBase.Process(Int32 primaryObjectTypeCode, Int32 secondaryObjectTypeCode, CorrelationToken correlationToken, CallerOriginToken originToken, UserAuth userAuth, Guid callerId)
   at Microsoft.Crm.Sdk.RequestBase.Process(CorrelationToken correlationToken, CallerOriginToken originToken, UserAuth userAuth, Guid callerId)
   at Microsoft.Crm.Sdk.CrmServiceInternal.Execute(RequestBase request, CorrelationToken correlationToken, CallerOriginToken originToken, UserAuth userAuth, Guid callerId)
   at Microsoft.Crm.Sdk.InProcessCrmService.Execute(Object request)
   at Microsoft.Crm.Application.Platform.ServiceCommands.PlatformCommand.ExecuteInternal()
   at Microsoft.Crm.Application.Platform.ServiceCommands.CreateCommand.Execute()
   at Microsoft.Crm.Application.Platform.SystemUser.Create(Boolean performDuplicateCheck)
   at Microsoft.Crm.Application.Platform.EntityProxy.CreateAndRetrieve(String columnSet, Boolean performDuplicateCheck)
   at Microsoft.Crm.Application.Forms.AppForm.RaiseDataEvent(FormEventId eventId)

Fortunately I had seen this one before, and fixing it is pretty easy.  Just switch the registry entry HKLMMicrosoftMSCRMAutoGroupManagement from 0 to 1.