Most Popular Posts

Tuesday 9 July 2013

Tuning your ConfigMgr 2012 Reporting Point For Speed

I have been doing some testing around this as the speed I see on the reporting node is often disappointing, and I have made some (not so shocking) discoveries. To speed up your reporting point do the following:


  1. Set the initial Size of the ReportServer$ database, by default it is 6mb! once you install a RP it jumps to around 90 and then starts to increase for every report you run. Set its initial size to 1024mb that should help.
  2. Set the autogrow on the database to 1024, it shouldn't ever grow beyond the initial 1024 anyway.
  3. Set the initial size of the ReportServer$ transaction logs to 1024mb
  4. Set the autogrow on the transaction logs, again 1024mb is fine,as long as you take a backup you should be fine, providing you....
  5. Set the recovery mode to SIMPLE. If you don't do this then be prepared to hit disk space issues down the line. Setting to simple commits the logs and starts afresh after a backup
  6. Set the ReportServer$TempDB inital size to 1024mb with autogrow at 1024mb again
  7. Split the ReportServer$TempDB into X number of files where X= as many cores as you have (e.g4 vCpus = 4 files) up to a maximum of 8 files (and I do recommend 8 if you can)
  8. Set the sizes of these files to 1024mb and their autogrowth to 1024mb
Restart the SQL services or the whole box and check out how fast it is, I can barely keep up :)

NB. This was all tested quick and dirty in a lab environment, so please size accordingly and monitor in your environment to ensure all is well.

Wayne

SCCM 2007 Migration failure due to site system named LOCALHOST

This post covers an issue I encountered during a migration and how to fix it.

If you are performing a Configuration Manager 2007 to 2012 Migration and have a site system in the console with the name LOCALHOST that holds the ConfigMgr site server database role as shown:



You will see the following error in the Migmctrl.log file when attempting to gather data from the source hierarchy in your 2012 environment:


To fix this you must run ConfigMgr setup from the 2007 Site server:

When the wizard launches be sure to select Perform Site Maintenance or reset the Site

On the desired action page select Modify SQL Server Configuration

On the SQL Server Configuration page change LOCALHOST to the name of the ConfigMgr 2007 server.



Allow the wizard to complete and review the log file when given the opportunity. You should now see in the console that the ConfigMgr site server database role is now held by the correct site system and not LOCALHOST.

Back in the 2012 environment, retry the data gather and you should have a little more success :)

Wayne