Gordon McKenna - System Center Operations Manager MVP - Inframon Ltd

Well although I hate to admit it being an OpsMgr guy, I have actually been getting my head around deployment planning for SCCM as of late as part of my ever expanding System Center role (no sarcastic comments please boys).

And I have to admit I have been finding it very interesting, and as I am a relative dummy when it comes to SCCM I thought I would start blogging about the stuff I am finding out, so you other SCCM dummys out there may possibly pick ups some tips (you never know maybe one of SCCM colleagues on WMUG may start doing the same with OpsMgr).

First of all I have been directed to some very good resources, first one being this guide from the deployment guys on rough sizing guidlines:

http://blogs.technet.com/deploymentguys/archive/2008/05/20/sccm-for-deployment-rough-sizing-guidelines.aspx#comments

Really good read.

Next, unlike OpsMgr which has guides that come in both downloadable word format as well as the readable online format, it appears that most SCCM content is ONLY available online, so I started off (after reading through the fundamentals), with the Configuration Manager Planning and Deployment Overview here:

http://technet.microsoft.com/en-gb/library/bb693806.aspx

I have to say mind that I was a bit dissapointed I couldnt just download this lock stock (somebody point me in the right direction if I am missing the guide in Word format), as I do like to print a copy off to peruse on the train on my way into London.

Point for Microsoft, If you want people to start treating the System Center like a suite then get some consistency on TechNet across the product sets.....

I then began wondering which version I should be focusing on and as R2 is almost upon us I thought that I would concentrate on this version, you can check out supported configurations here:

http://technet.microsoft.com/en-gb/library/bb680717.aspx

And finally, I wanted to know whether "out-of-the-stable" R2 would be supporting SQL 2008, and to my dissapointment the answer is no, check out this newsgroup thread here:

http://forums.microsoft.com/TechNet/ShowPost.aspx?siteid=17&PostID=3732354

I will let you no in my next SCCM post how I got on with the docs,

many thanks to Firdous for the tips

A question that came up recently from one of my fellow MVP's was whether or not hotfixes destined for Management Servers need to be applied against Gateway Servers and the simple answer is yes.

Here is the official reply from Clive Eastwood OpsMgr Support guru (and fellow Brit) on the OpsMgr product team:

Yes a GWS is treated the same as an MS. Applying an Agent/Server hotfix to a GWS (e.g. applying a MOMModules.dll hotfix) will apply the updates to server DLL’s as well as copying the msp file to the appropriate platform folders of the AgentManagement folder for distribution to managed agents (current and future).

David posted earlier on the release of the new Dell Management Pack, this pack has had a number of issues some which were actually caused by problems in OpsMgr which have now been addressed in a hotfix.

Unfortunately, it is not that obvious in the documentation about some of the things you need to do to take full advantage of this release so I want to point out a really good blog post from Kevin Holman on the product team that talks about some of these things

http://blogs.technet.com/kevinholman/archive/2008/08/11/updated-dell-mp-released-3-1-a01.aspx

Hi Folks, a heads up, to stop you making the same mistake as me.

I have just spent the last three weeks finishing up an OpsMgr rollout for a large manufacturing company in the UK as part of a server re-location project, and as they have a pretty well deployed SCCM infrastructure, I opted for AD Integrated for Agent deployment with the agent being delivered by SCCM.

The target for the agent was all Windows Servers in the domain, which should have made the agent roll-out pretty simple, however, I forgot to instruct the SCCM engineer to make an exception for my RMS, two Management Servers and two ACS Collectors, and he managed to physically deploy and agent to each of these boxes, the result was pretty catastrophic, as the Health Service on the MS’s simply stopped working. The action you may think was most obvious here was to roll back the agent but this actually resulted in ripping the guts out of the MS’s with all services refusing to start (even after a repair).

Luckily, I managed to pretty much re-install all of the MS’s back to their previous states but obviously this has meant re-configuring things like ACS and has resulted in a pretty significant outage for the client.

Moral of the story, make sure you make an exception for your OM infrastructure servers if planning an agent deployment via SCCM

Note for Microsoft, please make the OpsMgr agent or SCCM intelligent enough to know that a server is running a Management Server component..........

Gordo.

I have been busy doing a fair number of ACS Installs recently and thought I would put together a step by step guide for reference purposes as the information to do this end to end  is not in the same place in the guides which can lead to missed steps

ACS Database and Collector Server Install

1. Log on to the Management Server  with an account that is a member of the OpsMgr administrators group

2. Click on the OpsMgr Setup executable which On the install splash page click install “Install Audit Collection Server” from the menu to start the install wizard.

3. On the Welcome screen click next

4. Check the button to accept the terms in the license Agreement and click next

5. On the “Database Installation Options” screen leave the create a new database option checked and click next

6. On the “Data Source” screen, leave the default data source name as “OpsMgrAC”

7. On the “Database” screen leave the Remote database server option checked and add the database server machine name, the database server instance name and leave the database name as the default, click next

8. On the “Database Authentication” screen leave Windows authentication checked and click next.

9. On the “Database Creation Options” screen, check specify directories and choose the following paths:
Database file location -,
Log file location –
and Click next

10. On the “Event Retention Schedule” screen either leave the following defaults:
Local hour of the day to perform daily database maintenance: 02:00AM
Number of days and event is retained in the database: 14
or change as appropiate
Click next

11. On the “ACS Stored Timestamp Format” Screen select either the local timestamp or the Universal Coordinated Time (UTC) checkbox and click next
 
12. Click next on the summary page to install

13. When the install is finished log onto the SQL server and verify that the OperationsManagerAC database is installed

14. On the local server: , open Computer Management and Services and Applications, select Services, and confirm that the Operations Manager Audit Collection Service is present, that it is started, and that the Startup Type is set to Automatic.

ACS Reports Install

Installing the ACS Reports

1. Log on to the Management Server  with an account that is a member of the OpsMgr administrators group

2. Open explorer and navigate to the ReportModels folder in your Operations Manager install files: eg D:\SelectCDImage\ReportModels\.

3. Copy the folder "acs" locally to the C: drive: i.e. C:\acs

4. If using OpsMgr RTM or SP1 you will need to also copy the file “ReportingConfig.exe” from the SupportTools folder  to C:\acs.

5. Open a Command Window and navigate to the folder c:\acs

6. Run the following command:

UploadAuditReports <database\instance> http://<yourReportingServerName>/ReportServer C:\acs

note: you may see some warning errors as below on uploading the reports, these are expected and can be ignored

Finally, here is the bit that everyone misses

Configuring SRS

1. Open Internet Explorer and enter the following address to view the SQL Reporting Services Home page. http://<yourReportingServerName>/Reports<$InstanceName>

2. Click Audit Reports in the body of the page and then click Show Details in the upper right part of the page.

3. Click the Db Audit data source.
In the Connect Using section, select Windows Integrated Security (if not already checked) and click Apply.

I quite often have to carry out a split install of SRS for my OpsMgr deployments, this is normally down to the fact that most SQL admins wont allow IIS to be installed on their SQL boxes.

In these situations I typically have a large database server with the Ops and sometimes Datawarehouse DB's on, and one server with my RMS role. As I normally install the Webconsole on the RMS server to avoid any double hop issues, it always makes sense to me to also install the SRS front end here too, especially as the reporting is now accessible through the console which requires a connection to the RMS anyway.

The tricky part for a lot of people I talk to is getting the SRS split install to work, so I thought I would blog about how you do this step by step:

Installing A SQL Server Reporting Services Split Install

1. Make sure IIS is installed locally on the server.

2. Locate the SQL Install media and click on setup.exe

3. Click next on the “Registration Information” page

4. On the components to install page check the Reporting Services box and click next

5. On the “Instance Name” tab choose the default instance

6. On the “Service Account” tab choose Use a domain user account that has full access to the Data Warehouse (I usually use the SDK or data reader\writer account), make sure the start Reporting Services at the end of setup tab is checked and click next

7. On the “Report Server Installation Options” and “Error and Usage Report Settings” tabs click

8. On the “Ready To Install” tab click install to finish

9. When the install completes please run Service Pack 2 to update the components to the necessary service pack level

Configuring SRS

The next step is to configure SRS so it installs the report DB’s on the remote SQL Server

1. Go to Start, All Programs, Microsoft SQL Server 2005, Configuration Tools, Reporting Services Configuration

2. On the “Configure Report Server” screen click connect to access your local SRS instance

3. Click on the “Database Setup” tab on the left hand side, click Connect, in the “SQL Server Connection Dialog” screen specify the SQL Instance that the SRS DB’s will be installed too, leave Current User – Integrated Security selected as the credentials type and click OK
 
4. Next click the “New” button and leave the defaults but make sure “Create the report server database in SharePoint Integrated Mode” is unchecked, next click OK to create the new DB’s
 
5. Next, go to the “Report Server Virtual Directory” tab and check the box “Apply default settings” next to the New Button, the click apply

6. Go to the “Report Manager Virtual Directory” tab and check the box “Apply default settings” next to the New Button, the click apply

7. Go to the “Web Service Identity” tab and click apply

8. Click on the “Database Setup” tab again and on the left hand side and click the Connect button, in the “SQL Server Connection Dialog” screen specify the SQL Instance that the SRS DB’s are now installed too, leave Current User – Integrated Security selected as the credentials type and click OK to connect, now choose ReportServer in the database name pull down box and click apply

9. Finally, to test that the above steps have been carried out correctly, open up a browser and navigate to http:\\localhost\reports, if everything has been successful then you should see the reporting services home page.