First look at Microsoft Dynamics CRM 2011 – installation

Well, the next release of Microsoft Dynamics CRM is already out. In fact, it was released to customer download on 16th February – a month back. Here’s the press release and if you need to download a 90-day trial version you can do so here. The trial keys can also be found on the download page.

I’ve just finished an installation of the new version on Windows Server 2008 R2 64-bit using SQL Server 2008 R2 64-bit. It went smoothly with just one hiccup. I had selected domain accounts for running all the CRM services (make sure you select a different account for the Microsoft Dynamics CRM Sandbox Processing Service service than the rest or else you will encounter a warning that asks you to do so). On the System Checks step, where the setup verifies the selected settings against the environment, it threw two warnings under Microsoft Dynamics CRM Server User Input. The warnings were –

• The account specified to run the Microsoft Dynamics CRM application does not have performance counter permissions
• The account specified to run the Microsoft Dynamics CRM Asynchronous Processing Service does not have performance counter permissions

Here’s a screenshot –

This issue can be resolved by simply adding your service account to the local group Performance Log Users. To do this follow the steps below (do not close the CRM setup window, leave it as it is on the warnings step) –

1. Open Start -> Administrative Tools -> Computer Management.
2. Navigate to System Tools -> Local Users and Groups -> Groups.
3. Select the group Performance Log Users, right-click on it and select Add to Group...
4. Click on the Add button to select your service account.
5. Click on the OK button when done.

Back in the Dynamics CRM installation window, click on the Back button and then on the Next button. The setup will verify the settings again, and this time you should not see any warnings.

When you open CRM, you will be surprised – the user interface has undergone major enhancements and there are a lot of important new features. But, more about them in later posts…

Just one more thing, the other relevant downloads are here –

• Microsoft Dynamics CRM 2011 for Microsoft Office Outlook
• Microsoft Dynamics CRM 2011 E-mail Router
• Microsoft Dynamics CRM 2011 Software Development Kit (SDK)

In case you need to use Scribe AX adapter with .NET Business Connector and AOS on different servers or connect to multiple AOS instances on the same server…

A month back, I had posted about the issues faced while getting the Scribe AX adapter (version 1.1) connected to Dynamics AX 2009. Well, we had the AOS and Business Connector on different servers and Scribe wouldn’t allow that. So we had to install the Business Connector on the AOS server to get the adapter up and running. You can find the details here.

There was also this problem when we had to connect to multiple AOS instances on the same server. One instance of the Scribe AX adapter can connect to one AOS instance. We were able to get, at the most, two instances of the adapter running at the same time on the same server. You can see the details here. Since, it is required that the AOS and Business Connector (and consequently the Scribe AX adapter server component) be on the same server, we were limited to running (or connecting) to two AOS instances. Luckily, we did not have a need to connect to a third instance on the same server!

However, this may not be concern now. Scribe has provided a hotfix that allows the AOS and Business Connector to be on different servers. So, you can now have your AOS running on one server and your Scribe AX adapter server component (which requires the Business Connector) on a different server. Effectively, this also means that you can have three servers, each running the Scribe AX adapter server component and connecting to a different AOS (all of the AOS instances could be running on a single server – doesn’t matter). So, we now have both our issues resolved. Just that we need to set up one server (running the Scribe AX adapter server component) per instance of an AOS we wish to connect to.

Thanks to the Scribe team for providing a fix in a short time!

Also, my recommendation of what’s left now is to allow the Scribe AX adapter server component setup to install multiple instances on the same server by asking the user for a Windows service name.

Dynamics CRM 4 – Fixing query timeout issues with views

A few days back, the default views for a couple of entities in one of our Dynamics CRM 4 instance failed to open. The most notable was the “Active Contacts” view on the Contact entity. The same view continued to open properly on all other deployments. In fact, we had imported the organization from another instance of Dynamics CRM and the views were opening on the original instance. Below is the error that we were receiving. There’s nothing that could be deduced from it, other than something was failing.

The first step to troubleshoot was to enable tracing on the CRM instance. To do that, you have to make a few registry entries. The details are outlined here. The registry setting of TraceEnabled, TraceDirectory, and TraceRefresh are required. We, however, found out that even after setting the TraceDirectory, our trace logs were created in the default C:\Program Files\Microsoft Dynamics CRM\Trace directory. Maybe, the path is to be provided in a specific format, but that is yet to be investigated. Here is a view of our registry settings –

Once, the setting was done, the trace files generation started and we started getting files with names of the format ServerName-w3wp-wwwroot-yyyymmdd-X. The trailing X stands for the file number generated for a single day, and will typically have a value of 1. If you set the TraceFileSizeLimit registry flag, then each file will have a maximum size limit, and multiple files (with trailing 1,2,3…and so on) may get created for a single day.

We tried to open the culprit view again to have the trace generated. This is what we received in the log file –

[2011-02-02 04:04:51.8] Process: w3wp |Organization:f79g217f-763c-e045-ah72-895056hgyy76 |Thread: 9 |Category: Platform.Sql |User: s45g217f-333d-sddd-ehd2-643877rehh44 |Level: Error | BusinessProcessObject.ExecuteQuery
>Exception when executing query: select top 51 contact0.Telephone1 as 'telephone1', contact0.EMailAddress1 as 'emailaddress1', contact0.CreatedBy as 'createdby', contact0.LastName as 'lastname', contact0.FirstName as 'firstname', contact0.JobTitle as 'jobtitle', contact0.ContactId as 'contactid', contact0.CreatedByYomiName as 'createdbyyominame', contact0.CreatedByDsc as 'createdbydsc', contact0.CreatedByName as 'createdbyname' from Contact as contact0 where (contact0.StateCode = 0 and (contact0.DeletionStateCode in (0))) order by contact0.FirstName asc, contact0.ContactId asc Exception: System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
at System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader()
at Microsoft.Crm.CrmDbConnection.InternalExecuteReader(IDbCommand command)
at Microsoft.Crm.CrmDbConnection.ExecuteReader(IDbCommand command, Boolean impersonate)
at Microsoft.Crm.BusinessEntities.BusinessProcessObject.ExecuteQuery(CrmDbConnection dbConnection, IDbCommand command, ISqlExecutionContext context)

Please note that your GUIDs for the organization and user will be different from the ones specified above. The important line is the one highlighted in red. It specifies the query that failed to run at the SQL Server (again, your query may be different in case you have customized the view) and the exception thrown – Exception: System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. This clearly says that the query is taking a long time to execute and it timed out. We connected to the CRM organization database using SQL Server Management Studio and ran the query to find out the execution time. It was taking around 51 seconds to execute. It turned out that the default query execution timeout for CRM is 30 seconds. We ran the same query on other CRM instances and it ran within 5 seconds. So, that was why the views were opening on all other instances. The timeout values can be overridden by two registry settings OLEDBTimeout and ExtendedTimeout. In our case, since it was simply views (ExtendedTimeout is used for long running operations – imports & other stuff), we just needed to add the OLEDBTimeout registry setting. We set its value to 120 seconds and the view started working. You can see the detailed steps here (although the KB article refers to another problem, the steps in the Resolution section are for adding the timeout registry settings).

You can use this approach to fix timeout issues immediately, however for a more sustainable and long-term approach, the database indexes & query execution plans need to be looked at.

Photos of Bhigwan birding trip on 22nd-23rd January 2011

Photos of the birding trip to Bhigwan on 22nd and 23rd January are here (it’s a Picasa web album).

Again, thanks to Amit for clicking the photos as well as posting them….

Dynamics CRM 4 – Add a Deployment administrator using SQL

A couple of days back, someone accidentally removed the sole user added to the Deployment Administrators on one of our Dynamics CRM 4 installations. There was no way that we could access the Deployment Manager console. So, we decided to look into the CRM SQL Server database for a way to add a user as a Deployment Administrator. Since, all Dynamics CRM configuration (metadata & data) is stored in the MSCRM_CONFIG and other tenant specific databases we had a hunch that it should be possible. Furthermore, since the Deployment Administrators users are common to the entire CRM deployment (as opposed to any specific tenant) we figured out that we should look only into the MSCRM_CONFIG database.

Although the investigation lasted for quite some time (with a lot of tense moments), the solution proved to be very easy & swift.

Here’s what needs to be done –

1. In Dynamics CRM, navigate to Settings -> Administration -> Users and open the user whom you want to be added to the Deployment Administrator. In the window that opens for the user, look at the URL. It should be something like this –

   http://MyCRM/MyTentant/biz/users/edit.aspx?id={A GUID Here}
   The GUID that you see in the URL is the CRMUserId for the user account. Select this GUID and copy it (Ctrl + C).

2. Open Microsoft SQL Server Management Studio, and connect to the MSCRM_CONFIG database for your CRM installation. Open a new query window, and run the following query to retrieve a few identifiers for your user account.

   SELECT Id, UserId
FROM [MSCRM_CONFIG].[dbo].[SystemUserOrganizations]
WHERE CrmUserId = 'Your CRMUserId here'

   Note down the Id and the UserId returned in this query.

3. Now, we simply need to add a row to the SystemUserRoles table for this user, using the Id and UserId returned. The User role that we need to assign so that a user can act as a Deployment Administrator is Administrator with the GUID of 19cfbc8d-77ed-459e-9909-1bf1cc1b0430. You can get this information from the SecurityRole table. Use the following query to do add the required row –

   INSERT INTO [MSCRM_CONFIG].[dbo].[SystemUserRoles]
([Id], [SecurityRoleId], [SystemUserId], [UniqueifierId], [IsDeleted])
VALUES
('Your Id returned above', '19cfbc8d-77ed-459e-9909-1bf1cc1b0430',
,'Your UserId returned above', NULL, 0)

   That’s it. This should do the trick.

   Verify the changes by opening Deployment Manager now…

Hosting two instances of the Scribe AX adapter (ScribeAxServiceHost) on the same server (to connect to two AOS instances)

When the Scribe AX adapter server component (the Windows service, Scribe AxServiceHost, for adapter version 1.1 with Scribe Insight 7.0.1) is set up, we do a few changes to its configuration file (Scribe.AxServiceHost.exe.config).

Within the <AxServiceHost.Properties.Settings> configuration section, there is a section that says –

<setting name="aosServer" serializeAs="String">
<value>[your AX application instance]@[your server name]:[your TCP/IP port number]</value>
</setting>

Here we edit the text within the  <value>  tags, and replace with the actual values (the placeholder text blocks are self-explanatory and the actual values can be retrieved by logging into the AOS server and going to Start -> Programs -> Administrative Tools -> Microsoft Dynamics AX 2009 Server Configuration). Then, we go to Start -> Programs -> Administrative Tools -> Services and restart the Scribe AxServiceHost service. Once we restart the service our new settings take effect.

This suffices when we need to connect to only one AOS instance (you might have easily guessed that, since the Scribe.AxServiceHost.exe.config file only allows one instance of the <setting name="aosServer" serializeAs="String"> tag). If there is a need to connect to multiple AOS instances that reside on the same server then we have a problem. Also, we can not have the Scribe AxServiceHost service on a server different from the AOS (for more details, look at my earlier post here). So, if you are thinking that we can have multiple servers running the Scribe AxServiceHost service each referring to a different AOS, then don’t, as that won’t work.

So, if you need to connect Scribe to multiple AOS instances running on the same server, the solution is to set up multiple instances of the Scribe AxServiceHost Windows service, each referring to a different AOS instance. To do this, log into the server hosting the multiple AOS instances with administrative privileges. Open Windows Explorer and navigate to the folder that contains the files for the Scribe AxServiceHost. By default this is C:\Program Files (x86)\Scribe\Dynamics AX Server on a 64-bit operating system and C:\Program Files\Scribe\Dynamics AX Server on a 32-bit one. Copy the folder ScribeAX Service and paste it in the same location. A new folder named ScribeAX Service - Copy will be created below the existing folder with name ScribeAX Service. Rename the new folder to something that will help you identify the AOS instance you will use it to connect to. We named it ScribeAX Service - 10, suffixing our internal identifier for the AOS instance (10). Navigate within the new folder and open the file Scribe.AxServiceHost.exe.config in Notepad with Administrative privileges. Now, the Scribe AxServiceHost is just a Windows service hosting the WCF service that the Scribe Workbench (or integration packages) connect to. We need to make another instance of this WCF service running on this server. To do this, we have to run this WCF service on ports other than the ones on which the already configured instance of Scribe AxServiceHost is running. Locate the tag <services> within the tag <system.serviceModel>. You should see the configuration of a WCF service with name AxServiceHost.AxaptaService within. There will be four endpoints configured (each with a <endpoint> tag) and a host setting (with a <host> tag). The first two endpoints (for wsHttpBinding) will not need any changes as there is not port specified here. The third endpoint (for TCP binding) looks like this –

<endpoint address="net.tcp://Your server name/AxServiceHost/AxaptaService/"
binding="netTcpBinding" bindingConfiguration="netTcpBinding_ScribeService"
contract="AxServiceHost.IAxaptaService" />

By default, if you do not specify the port for TCP binding the 808 port is used. So, change this entry to something like this, to explicitly specify a new port –

<endpoint address="net.tcp://Your server name:8732/AxServiceHost/AxaptaService/"
binding="netTcpBinding" bindingConfiguration="netTcpBinding_ScribeService"
contract="AxServiceHost.IAxaptaService" />

Here, I have used the port 8732, however, you can use any available port of your choice.

Now, look at the next endpoint. This will be the one for the MEX (metadata exchange) for the above TCP binding endpoint. This is used by clients to retrieve the WSDL for your web service. It should look like this –

<endpoint address="net.tcp://Your server name/AxServiceHost/AxaptaService/mex"
binding="mexTcpBinding" bindingConfiguration="" contract="IMetadataExchange" />

This should be edited to specify the same port as the one used above. So, I edited it to look like this –

<endpoint address="net.tcp://Your server name:8732/AxServiceHost/AxaptaService/mex"
binding="mexTcpBinding" bindingConfiguration="" contract="IMetadataExchange" />

Now, look at the <host> tag below. There should be a <baseAddresses> tag in it, containing a base address entry that looks like this –

<add baseAddress="http://Your server name:8731/AxaptaService/" />

Here, edit the entry to change the port to an available port. Do not use the port specified above for the TCP binding. Here is what I used –

<add baseAddress="http://Your server name:8733/AxaptaService/" />

With these changes done, you are ready to run your WCF service alongside the existing one. There is just one more change to be done in the configuration file – you need to specify the new AOS instance that you wish to connect to. Locate the tag <setting name="aosServer" serializeAs="String">. Within the tag, we specify the AOS instance details as follows –

<value>Your AOS instance name@Your AOS server:Your AOS instance port</value>

I edited mine to look like this –

<value>MyAOS10@MyAOSServer:2713</value>

Save the Scribe.AxServiceHost.exe.config and close Notepad. Now, open a Command Prompt with Administrative privileges (Start -> Programs -> Accessories -> Right-click on Command Prompt -> Select Run as Administrator). Change the directory to C:\Windows\Microsoft.NET\Framework64\v2.0.50727 (for 64-bit operating system) or C:\Windows\Microsoft.NET\Framework\v2.0.50727 (for 32-bit operating system). Use the command below to do that –

For 64-bit operating system –

cd "C:\Windows\Microsoft.NET\Framework64\v2.0.50727"

or for 32-bit operating system –

cd "C:\Windows\Microsoft.NET\Framework\v2.0.50727"

Now, run the following command to install the new copy of the Scribe AxServiceHost as a Windows service.

For 64-bit operating system –

installutil.exe "C:\Program Files (x86)\Scribe\Dynamics AX Server\ScribeAX Service - 10\Scribe.AxServiceHost.exe"

or for 32-bit operating system –

installutil.exe "C:\Program Files\Scribe\Dynamics AX Server\ScribeAX Service - 10\Scribe.AxServiceHost.exe"

Replace the ScribeAX Service - 10 here, with the name of the folder where you copied the existing ScribeAX Service folder in the first step. It will ask you for the user account details under which you wish to run the Windows service. Specify a local/domain account here. The Windows service that gets installed will run under this user account. If you are using Windows authentication for Scribe, this account will need access to your Scribe SQL Server database (by default, the SCRIBEINTERNAL database).
Now, if you go to Start -> Programs -> Administrative Tools -> Services (or refresh it if it’s already open), you should see a new Windows service named, AxService. You can verify the location by right-clicking on it and checking the “Path to Executable” section of the dialog box that opens.

Now, simply start the Windows service. In Internet Explorer, browse to http://Your server name:8733/AxaptaService/ (replace the Your server name:8733 with your server name for the AxService and port – the one specified for the <base address>). This should give you the web service details page with the WSDL link.
You can then use Scribe Workbench and create a connection with the Microsoft Dynamics AX Adapter using the URL http://Your server name:8733/AxaptaService/.

If you repeat this process once more you will get an error from InstallUtil.exe saying "System.ComponentModel.Win32Exception: The specified service already exists". This is because the InstallUtil.exe will try to install a service with the name AxService and that one already exists. I’m still trying to figure out how to pass a service name to InstallUtil.exe, so that we can have as many instances as we want, and not just two. Since, the default Scribe setup installs the same executable as ScribeAxServiceHost, and not AxService, it means that it supports specifying a custom service name. But that should be a custom parameter for the InstallUtil.exe that I’m not aware of as of now. That will be subject of another post, soon…

For information of InstallUtil.exe, go here.

Connecting to Dynamics AX 2009 using Scribe AX adapter…

After a lot of struggle, we finally managed to get Scribe (7.0.1) to connect to our Dynamics AX 2009 instance. The Scribe AX adapter works via a WCF service hosted within a Windows Service (ScribeAxServiceHost). Scribe has provided this service as an installable. The integration packages connect to the WCF service, which in turn connects to the Dynamics AX AOS using the .NET Business Connector. The architecture of Scribe AX adapter is detailed in its Help file. As it turns out the installation guide depicts a Dynamics AX deployment where the AOS & .NET Business Connector are on the same server. We have a deployment configuration where the AOS & all clients (including the .NET Business Connector) reside on separate servers.

Our first attempt was to install the server-side Windows service of the Scribe AX adapter on the server hosting the .NET Business Connector (the AOS being on another server). The Windows service (ScribeAxServiceHost) would start, we could browse the WSDL of the WCF service from Scribe Workbench (on yet another server), but we never could connect to the AOS through this WCF service. The errors thrown were very cryptic. A lot of troubleshooting with the SPNs (service principal names) and network monitoring ensued, but we were not able to get the adapter to connect to the AOS.

Finally, we got the .NET Business Connector and the server component of the Scribe AX adapter (Windows service – ScribeAxServiceHost) installed on the AOS server itself. That did the trick…the Scribe Workbench was now able to connect to the AOS.

The Scribe Adapter for AX as of now (version 1.1) requires that it’s server component Windows service be installed on the same server as the AOS and the .NET Business Connector.