Happy days!!!
As of the latest update (20/01/2013) to the downloadable server installation files for CRM 2011, the installation files now include CRM Update Rollup 6 (Build 05.00.9690.1992)... yay!
This will definitely help with the long winded multi-step patching process we have had to use up to now, especially when installing multiple front end servers.
You can find the installation files on the Microsoft Download Center here.
Showing posts with label Update Rollups. Show all posts
Showing posts with label Update Rollups. Show all posts
Thursday, 31 January 2013
Thursday, 19 August 2010
CRM build and Update Rollup numbers
Ever needed to figure out what Update Rollup was running on a CRM server. Hopefully this table will help you.
I'll try to keep it as up to date as possible.
| Version | Build Number | Released on |
| RTM | 4.0.7333.3 | 19/12/2007 |
| Rollup 1 | 4.0.7333.1113 | 24/11/2008 |
| Rollup 2 | 4.0.7333.1312 or 4.0.7333.1316 | 15/01/2009, 08/02/2009 |
| Rollup 3 | 4.0.7333.1408 | 12/03/2009 |
| Rollup 4 | 4.0.7333.1551 | 0705//2009 |
| Rollup 5 | 4.0.7333.1644 or 4.0.7333.1645 | 02/07/2009 |
| Rollup 6 | 4.0.7333.1750 | 27/09/2009 |
| Rollup 7 | 4.0.7333.2138 | 22/10/2009 |
| Rollup 8 | 4.0.7333.2542 | 17/12/2009 |
| Rollup 9 | 4.0.7333.2644 | 11/02/2010 |
| Rollup 10 | 4.0.7333.2741 | 08/04/2010 |
| Rollup 11 | 4.0.7333.2861 or 4.0.7333.2862 | 03/06/2010 |
| Rollup 12 | 4.0.7333.2935 | 02/08/2010 |
I'll try to keep it as up to date as possible.
Tuesday, 17 August 2010
Keeping a hold on your database size
CRM databases have a tendency to grow very quickly. I've seen growth on smaller 50-ish user sites of easily more than 1GB per month. This gets bigger even quicker if you have a workflow and e-mail heavy solution.
I wont cover the e-mail issue in significant detail here other than to say some thought should always be given to the storage of e-mails in CRM and more specifically, attachments. This also applies to all other methods for saving attachments into the database. Some things to consider:
The other area and the one I'm exploring in detail here is the asynchronous operation tables in CRM. With every system job and/or workflow, new records will get written in to these tables (specifically the Asyncoperationbase and Workflowbase tables) Over time as your system goes through the motions of your various business processes, match code updates, system expansion tasks and all the rest, these tables can get very, very big; sometimes containing millions of records, causing not only a storage problem but almost certainly giving us some performance headaches too.
Fortunately Microsoft have recognised this and given us a few ways of dealing with the issue as part of the Update Rollup process.
So first off we have 2 options, both enabled via the addition of new registry keys:
My general answer to the above challenge is to enable the 'AsyncRemoveCompletedJobs ' registry key, but not the 'AsyncRemoveCompletedWorkflows' key. This means that we can reclaim some space from the other system jobs, while leaving the workflow history in place to support our MI requirements.
One last caveat; these registry cahnges are not restrospctive. In other words once the specific feature is enabled it will only remove jobs/workflows instanciated after the change, not historical data. To get around this the kind folks at Microsoft have provided us with some SQL swcripts that will remove historical data from the tables in question.
The article can be found here: http://support.microsoft.com/kb/968520/
A cautionary tale: The script provided by Microsoft deletes all completed jobs, workflow included. So if you intend to replicate the functionality of retaining completed workflow history as per the above registry keys, you will need to modify the script accordingly to not remove records where OperationType = '10'. If you dont do this you lose everything... and I'm talking from painful experience here :(.
I wont cover the e-mail issue in significant detail here other than to say some thought should always be given to the storage of e-mails in CRM and more specifically, attachments. This also applies to all other methods for saving attachments into the database. Some things to consider:
- What to set the CRM maximum file size to (this cant be bigger than 8192 kilobytes). Keeping it smaller will improve database size, but will mean that larger attachments will not be saved.
- When to promote an e-mail to CRM - do you really need every e-mail (and attachment) when a large amount of correspondence can often just be noise, with only certain elements of a conversation actually being relevant.
The other area and the one I'm exploring in detail here is the asynchronous operation tables in CRM. With every system job and/or workflow, new records will get written in to these tables (specifically the Asyncoperationbase and Workflowbase tables) Over time as your system goes through the motions of your various business processes, match code updates, system expansion tasks and all the rest, these tables can get very, very big; sometimes containing millions of records, causing not only a storage problem but almost certainly giving us some performance headaches too.
Fortunately Microsoft have recognised this and given us a few ways of dealing with the issue as part of the Update Rollup process.
So first off we have 2 options, both enabled via the addition of new registry keys:
- AsyncRemoveCompletedJobs (http://support.microsoft.com/kb/974896)
This will remove all completed Async jobs in CRM of the following types:CollectSQMDataPersistMatchCodeFullTextCatalogIndexUpdateContractStates - AsyncRemoveCompletedWorkflows (http://support.microsoft.com/kb/974896)
This will remove all completed workflow jobs from both the AsyncOperationBase and WorkflowBase tables.
My general answer to the above challenge is to enable the 'AsyncRemoveCompletedJobs ' registry key, but not the 'AsyncRemoveCompletedWorkflows' key. This means that we can reclaim some space from the other system jobs, while leaving the workflow history in place to support our MI requirements.
One last caveat; these registry cahnges are not restrospctive. In other words once the specific feature is enabled it will only remove jobs/workflows instanciated after the change, not historical data. To get around this the kind folks at Microsoft have provided us with some SQL swcripts that will remove historical data from the tables in question.
The article can be found here: http://support.microsoft.com/kb/968520/
A cautionary tale: The script provided by Microsoft deletes all completed jobs, workflow included. So if you intend to replicate the functionality of retaining completed workflow history as per the above registry keys, you will need to modify the script accordingly to not remove records where OperationType = '10'. If you dont do this you lose everything... and I'm talking from painful experience here :(.
Subscribe to:
Posts (Atom)
