Wes Weeks

Working with a client in our Multi-tenant CRM environment who was doing a database migration into CRM and as part of the process, a backup of their Organization_MSCRM database was taken just prior to starting the migration in case it needed to be restored and run a second time.

In this case it did, so I restored the database and let the client know he should be good to go.  A few hours later I received a call that they were unable to add some new users, they would appear as available when using the add multiple user wizard, but anyone added would not be added to CRM.  It was also disucussed that these users had been added to CRM initally AFTER the database backup had been taken.

I turned on tracing and tried to add the users through both the single user form and multiple user interface and was unable to do so.  The error message in the logs wasn't much help:

Unexpected error adding user a.jones@domain.com: Microsoft.Crm.CrmException: INVALID_WRPC_TOKEN: Validate WRPC Token: WRPCTokenState=Invalid, TOKEN_EXPIRY=4320, IGNORE_TOKEN=False

Searching on Google or bing didn't offer any assitance.  Apparently not a very common problem, or no one has been able to resolve.

I did some searching in the MSCRM_CONFIG database and found that their are several user tables there and after getting my head around the structure found that there were enties here for users that were not part of the restored DB.  It seems that new users are added to both the Orgnaization_MSCRM and MSCRM_CONFIG and after the restore these were out of sync.

I needed to remove the extra entries in order to address.  Restoring the MSCRM_CONFIG database was not an option as other clients could have been adding users at this point and to restore would risk breaking their instances of CRM. 

Long story short, I was finally able to generate a script to remove the bad entries and when I tried to add users again, I was succesful.  In case someone else out there finds themselves in a similar situation, here is the script I used to delete the bad entries.

DECLARE @UsersToDelete TABLE

(

  UserId uniqueidentifier

)

Delete From [MSCRM_CONFIG].[dbo].[SystemUserAuthentication]

Where UserId in (Select UserId From @UsersToDelete)

Delete From [MSCRM_CONFIG].[dbo].[SystemUserOrganizations]

Where UserId in (Select UserId From @UsersToDelete)

Delete From [MSCRM_CONFIG].[dbo].[SystemUser]

Where Id in (Select UserId From @UsersToDelete)

While trying to delete a sharepoint web application, I received the following error:

An object of the type Microsoft.SharePoint.Administration.SPIisWebsiteUnprovisioningJobDefinition named "Unprovisioning SharePoint - 80" already exists under the parent Microsoft.SharePoint.Administration.SPWebService named "".  Rename your object or delete the existing object.

Very little available information about this error, but what appears to have happened is that because this is the second time I've tried to delete this web application, and I had the same name for each, it is unable to create the unprovision job since it already exists.

To fix, I did the following:

Go to
Central Administration --> Monitoring --> Check Job Status
Click Job Definitions under timer links on the left
Delete the job with the name in quotes (i.e. 'Unprovisioning SharePoint - 80')

You should now be able to delete the web application.

Worked on a CRM which had a need to limit the users that could be chosen to a specific OU.  This should be simple enough with the CRM deployment config tool following these instructions:

http://support.microsoft.com/kb/959549

However it did NOT work.  The error I got was:

Command failed with the following message: The parameter does not start with '-';

The command I used that gave me this error was

Microsoft.Crm.DeploymentConfigTool.exe userorgsettings update -organization:<ORG_NAME> -propertyname:UserRootPath -propertyvalue:LDAP://mydomain.local/OU=CRM Users;DC=mydomain;DC=local

Exactly as the instructions indicated.  Searched the net and could not find any help on this.  After several hours of frustration, I figured out the cause.

Turns out, you have to put the domain OU property in quotes.  The command that worked was:

Microsoft.Crm.DeploymentConfigTool.exe userorgsettings update -organization:<ORG_NAME> -propertyname:UserRootPath -propertyvalue:LDAP://mydomain.local/OU=CRM Users;DC=mydomain;DC=local

It appears that the issue is that the command is reading the colon after the LDAP as indicating another parameter.

Happy Coding!

My first inplace upgrade of a MOSS 2007 farm to sharepoint went pretty smooth. I read the preupgrade documentation and was comfortable with the steps.  Since it was a fairly new installation of Moss changes were minimal and I wasn't anticipating too many problems

The one issue I got was after installing the software on all of the farm.  I went to the first machine which ran Sharepoint 2010 central administration and ran the Sharepoint 2010 Products Configuration Wizard.  I received the message that I would need to run the configuration on each server in the farm.  Fair enough, I expected as much.

The wizard completed without issue on the first server, but when I tried to run it on the others it hung with a "waiting to get a lock to upgrade the farm" message.  It hung for about 10 minutes and then the wizard failed.  Did a few searches on Google and Bing and got 0 results for that message.  None, Nothing, Zilch.  I'm on my own...

For grins, hit the help button on the configuration wizard and it seemed to indicate that the configuration wizard needed to be run on all farm servers simultaneously.  I started it again on the first server to the point I got the message about needing to be run on all servers on the farm and then started the wizard on the other servers and ran it to that point as well.  I then clicked ok on the first server and then the subsuquent servers.

It took a while and it did hang on the lock message for some time, but then it did kick off and completed succesfully on all of them.  Yeah!

Hope this helps someone else!  Now there should be at least one post with this error message on it!

Struggled to get a Silverlight Application to load in the browser.  Checked and double checked that the .xap mime type was succesfully registered.  It was working correctly on our other machines.

The .xap file was in a folder called ClientBin.  Tried connecting directly to the xap in the browser by navigating to it directly, and it was found, something that wouldn't have happened had the mime type not been correctly registered.

Turns out the cause was a 'Debug' folder that was also in the folder where the .xap file was located.  Although this folder was empty, for some reason silverlight was checking/looking here anyway even though the source setting in the object tag was set correctly.  Removing this empty folder solved the problem.

You gotta love this work sometimes...

Spent the last few hours trying to get an ASP.Net web/silverlight project to compile.   Every project in the solution would build fine but the web project wouldn't .  The frustrating part is the compile was showing 0 Errors so I didn't know where to start.

In the past these kind of strange errors have been fixed by numberous methods and I tried them all:

• Deleting everything from the bin and obj directories
• Recreating the project
• Recreating the solution
• Deleting and re-adding all references
• Deleting and readding the silverlight application
• Rebooting the computer (the universal cure)

Nothing worked.  There were a few pages I found on a FWSE that mentioned similar issues but nothing that seemed relevant to my situation.  Started getting very frustrated.  My computer can kick my ass at chess, but I'm pretty sure I can take it in kickboxing and I was about to let it find out...

Then I remembered the MSBuild output window.  I wasn't displaying this (I don't think it displays by default anymore) and turned it on and then went into options in visual studio to deliver a detailed output.

There the problem was:   Task "RdlCompile" -- FAILED

The issue turned out to be an RDLC (reporting) file.  There were a lot of warnings coming from this report, something about overlapping fields, but nothing that gave any kind of indication that it would keep the app from compiling.  The warnings only indicated that there might be rending problems, so I wasn't concerned about them.  Guess I should have been.

Long story short, removed the offending report and the application compiled.

Hopefully I can save someone else out there some time and grief...

When developing for CRM, we like to keep our business login contained within its own class to be shared and used by other parts of the system.  Most all of our CRM implementations have other applications accessing CRM in one way or another so this approach works well.  This was fairly straight forward wtih the 3.0 callout model, you just had to put them in the same directory with your custom callout  (C:\Program Files\Microsoft CRM\Server\bin\assembly\  in most cases) .

The way around this is to either put your assemblies in the GAC, or drop the assemblies in the bin directory of the CRM Web application (which is the route we chose).

Another caveat is your assemblies MUST be signed.  This was a bit of a pain to get working because we had a few unsigned third party assemblies and a signed assemblie can only reference other signed assemblies.  Probably the biggest issue was the Plugin deployment tool registered the unsigned assemblies without any issue, and we were without any error messages explaining why our code wasn't running.  In CRM 3.0 you could use unsigned assemblies by setting a config setting to 'allowUnsignedAssemblies' to true.

Hope these two pointers helps you out with your development...

We are building an application in Silverlight 2 using WCF for data access.  Everything has been going fairly well, but one of the developers on my team came across this error trying to insert some data:

"The remote server returned an error: NotFound"

Now the error seems to suggest that there is something wrong with the service.  Binding isn't correct, something wrong with the contract interrface, etc.  If you've ever tried to debug a silverlight applicatino, you know you can't attach to it with something like fiddler to see what traffic is being sent across the wire.  Very frustrating and significant time was spent  looking into the problem.  There are several posts on this issue and they all seem to suggest that this is where you need to look.

Turns out it had nothing to do with WCF.  The method being invoked by the web service was erroring but the error information itself wasn't being propogated.  It was sending this 'NotFound' message. 

So if you run across this problem, right some tracing or test cases to ensure the method wrapped by the web service itself works.  I beat the developer on my team with a wet noodle for not having tested his method prior to exposing it as a service.

Received an error Could not load file or assembly 'PresentationCore'  when trying to deploy and run a WCF service project.  It had been working fine for months without issue.  Turns out that the PresentationCore.dll had somehow been copied to the bin directory.  Removed this file and the site worked.

Still trying to figure out how/when this occured in the build...

Running Windows Vista 64 bit, Sql Server 2008 on a remote server.  Using ASP.Net and the Report Viewer control on an asp.net page for a local report.  Was also using IIS to host the web site instead of using the web server built into Visual Studio 2008.

Searched and tried everything I could find on the net trying to fix this freaking error.  On a whim (and because I didn't know what else to do and was trying everything I could think of) changed the IIS 7.0 app pool to the classic app pool.  Angels came singing down from the sky and my report worked.

What a PITA!  Hope this post helps someone else.

While performing an update to some code originally written for CRM 3.0 which I was upgrading to 4.0 and using the new 2007 version of the web services, I found myself getting an unusual error during one of the callouts.  The code created a new custom entity from the data in an existing entity.  This code was orginally written by another party and I"m not sure why they didn't use the mapping features in CRM to do this but it was coded manually.

The entity with typecode '8' was not found in the Metadata Cache.

Never having seen this before it of course took a lot of time digging through the event viewer and trace logs to find the source of the error.  In this case, it came down to one line:

newEntity.OwnerId = originalEntity.OwnerId

In a nutshell: the 'type' attribute on the originalEntity which had just been read out of CRM using the web services was '8', however when creating/setting the type on create the attribute field needs to be the name of the entity.  In this case, since the owner was a system user, the type field needed to be set to 'systemuser'

One would think that the inbound and outbound values could be the same or possible set up to parse for both a type code of or the type name.....

Anyway, if someone else comes across this or a similar problem, I hope this helps.

The CRM 4.0 installer has a nice new feature.  The ability to get upgraded setup files prior to running the instalation.  A nice step forward to hopefully address setup issues which are often present in the first release of the components.

Now for my Grip...

I've rarely been lucky enough to get it right the first time.  Usually I have to run the installer, fix a few things, and repeat until succesful.

The problem is that their isn't any 'memory' of the upgraded setup files.  If you have to run the installer a second time, you have to download the files again.  The connection I had was slow enough that it took nearly 20 minutes to update the setup files the first time.  When it came around to do it again, I wasn't patient enough to even consider going through that pain a second time and skipped the update.  I'd prefer not to go with that approach ;)

So if anyone from the MS team gets this message somehow, keep the upgrade strategy but provide a way for the updates to e maintaned or downloaded as a seperate file.  Will help us in he trenches out quite a bit.

While performing an upgrade from Microsoft Dynamics CRM 3.0 to 4.0, the upgrade installer halted early on with the following error message:

Microsoft.Crm.Setup.Server.ShutdownCrmServerAction failed

Turns out that at some point the IIS Admin service was shutdown and disabled.  Not sure how this occured since I had been running CRM 3.0 just prior to the install.

So if you get unlucky enough to get this message, open up your services and Enable/Restart your IIS admin service.  The setup continued without a hitch after that.

After installing sp1 on Windows Vista, my previously created web sites would no longer start and I got the following error:

WebDev.WebServer.exe has stopped working
Unable to connect to the ASP.NET Development Server

with the following exception:

System.Net.Sockets.SocketException was unhandled
  Message="An attempt was made to access a socket in a way forbidden by its access permissions"
  Source="System"
  ErrorCode=10013
  NativeErrorCode=10013
  StackTrace:
       at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
       at System.Net.Sockets.Socket.Bind(EndPoint localEP)
       at Microsoft.VisualStudio.WebHost.Server.Start()
       at Microsoft.VisualStudio.WebServer.WebServerApp.Main(String[] args)

The work around?  Unbind from Visual Source safe, delete the web project from the solution, rename the folder where the website is stored and then re add to the solution as an existing web site and then bind to source safe again.

While this works, I would prefer not to have to rename every folder where I have a web site.  The issue appears to be that somewhere Visual Studio stores all of the information about a web site that has been created.  If you don't perform the folder rename, when you add the web site back in you will see that it has the same dynamic port settings it had originally.  It is renaming that forces the new port and whatever else is going on behind the scenes that restores the functionality.

I've tried to find out where this site info is stored so I can delete it or correct it, but have been unsuccessful.  I've searched in the registry, tried deleteing the temporary asp.net files and poked around the numerous config files and have been unable to find it so I'm stuck with the rename option.

Does anyone know where this is stored or how to clear it out so VS will reset itself for these sites?

Another issue that may be faced when deploying custom .Net applications in the CRM root directory is the following error:

'Microsoft.Crm.WebServices.Crm2007.MultipleOrganizationSoapHeaderAuthentica­tionProvider,
Microsoft.Crm.WebServices, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' doesn't exist.

You can resolve this one of two ways...

1.  Add the following to your applications web.config (not CRM's web.config!)

<assemblies>
<clear/>
<add assembly="*"/>
</assemblies>

2.  Go to the crm bin directory for IIS and either copy the Microsoft CRM.WebServices.dll to the GAC or to the bin directory of your custom ASP.Net application