I found a nice utility (Customization Comparer) today for comparing two versions of a customization. This utility takes 2 xml files with CRM customizations and this gives you a visual overview changes in the different customization areas.
This is my second blog in the series of moving from CRM 4 to CRM 2011 in different scenarios. My first blog described the alternative of move a CRM 4 installation to new SQL Server 2012. After some consideration, the customer has decided to update the CRM 4 solution to CRM 2011 instead of just moving to a new SQL Server. The actual move to the new SQL Server 2012 involved a additional cost since the CRM 4 had to be updated with latest Rollup 21 to be compatible with SQL Server 2012.
After some googling and reading through the quite large, unreadable, exhausting to read. Yes, you get the information you need, but I can’t understand why Microsoft can’t write better installation guides. They surely have the man power.
After some consideration, I decided to do the following:
- Install a new CRM 2011 server and use the new SQL 2012 server
- Take a backup of the organisation database on the old SQL 2005 server
- Use CRM 2011 Deployment Manager to disable/delete the current “dummy” organsation
- Restore CRM 4 organisation database (from SQL 2005) on the new SQL 2012 server
- Use CRM 2011 Deployment Manager to import the CRM 4 organisation database
Today, I got a request from my team to fix a TFS access for a development RDP that wasn’t part of our standard domain. In addition, this developer RDP had Visual Studio 2008 and required to connect to our TFS 2010 server.
After some some retries to get the TFS connection working from the developer RDP, I had to turn to google for the solution, and I found a very useful post by Jason Barile. This post has several connection scenarios where the Visual Studio version differs from the Team Foundation Server version.
In my scenario, where I was trying to connect to a TFS2010 with a VS2008 development environment, I had to download and install the following:
The installation order is important, and the next question was how the connection string from VS2008 should look like. After some more reading and testing, I found the following format on the TFS2010 connection string:
I had a bit problems by using the standard domain users for accessing from the develop RDP, so I took the shortcut by creating a local user on the TFS server and use this user to connect to the TFS server (servername from URL above).
Today I’m installing CRM 2011 Server for a customer from a clean server install, and had to restart and handling files through Windows Explorer. Something thart has annoyed me for a while and I have been to lazy to google, until today, is to set the default startup folder for windows explorer.
The default startup folder is the “Libraries” folder. For some reason I wanted to have long path as startup folder, but below I’m just setting the folder to “C:\Logging\App1”. Find the “Windows Explorer” shortcut, right-click it and select “Properties”. On the “Shortcut” tab you change the “Target” attribute according to your folder.
%windir%\explorer.exe /select, C:\Logging\App1
It has been a lot of CRM 4 deployement stuff lately. When end user configure the CRM Outlook they get some weird URL against the CRM test server, instead of the production server. This made going deep into the CRM configuration database (MSCRM_CONFIG) looking for a reference. I had to add a search for string stored procedure and found references in several tables. One of these tables was MSCRM_CONFIG.DeploymentProperties.
We opened a Microsoft support ticket, where I got my suspicions confirmed. Initially, I wanted to make an UPDATE in the MSCRM_CONFIG database. This mas recommended by some CRM MVPs, but Microsoft support gave the link to a tool doing the same task more safely.
For my case where the Outlook client receieved invalid server name (CRM test server), I had to change the properties ‘webapprootdomain’ and ‘sdkrootdomain’.
My DOS commands to fix the problem:
microsoft.crm.deploymentconfigtool addresssettings update -webapprootdomain:crmsrv:5000 microsoft.crm.deploymentconfigtool addresssettings update -sdkrootdomain:crmsrv:5000 microsoft.crm.deploymentconfigtool asyncsettings update -sdkrootdomain:crmsrv:5000
Happy CRM deployment!
This week I have been lurking around the issue of planning an upgrade for a CRM 4 solution where CRM databases shall be moved to a new SQL Server. Microsoft has a standard description that I’ve been using, titled “Move CRM 4.o deployements“. But first I needed to find out any compatibility issues.
I logged into the customer servers and found the following:
- CRM server: CRM 4 with Rollup 20
- Current CRM SQL Server:
- Windows Server 2003 Standard with SP2
- SQL Server 2005 Sp2
- New SQL Server: SQL Server 2012 (no SP)
Since CRM 4 is pretty old, and SQL Server 2012 is just released, I had to check the requirements for the update. What CRM Rollup was required to be able to work with SQL Server 2012? From the Compatibility List, I found out that CRM 4 Rollup 21 was compatible with SQL Server 2012 with and without SP1. It is always a good to have the latest service packs, but in this case the service pack (SP) was in state CTP (Communite Technology Preview). This is a kind of beta release of the service pack and is not intended to customers that is not testing specific functionality that this CTP is addressing. So for this time, I’m not upgrading the SQL Server 2012 with any Service Pack.
To find the current Rollup for a CRM 4 installation, you go to the “Help | About” in the upper right corner on the menu. The build number represents the Rollup (version). Use the Build number List on the vidmar.net to determine the actual Rollup number.