Friday 13 July 2012

Configuring SCOM 2012 - Part 1

After completing the installation, SCOM was installed in eval mode.  Assigning the product key is done in poweshell, so I opened the Operations Manager shell and ran Set-SCOMLicense -ProductId "licensekey".

I then checked the licence via Get-SCOMManagementGroup | ft skuforlicense, version, timeofexpiration –a, although found I had to perform a reboot for it to take effect.  It can also be verified in the Ops Manager console in Help > About.
Next, I wanted to install some relevant management packs.  For now I just opted for packs that are relevant to components I've already deployed to the lab.  I'll add additional management packs as I grow the lab.
After they had been selected, it was just a case of clicking import, this completed successfully for all the packs I had selected.
Next, I wanted to add some servers to actually monitor. As I want to be using the SCOMAA account I created earlier to do this I need to get it added to each server as a local administrator.  Rather than doing this on a case-by-case basis I've opted to do it via Group Policy.

I logged onto one of the DC's and created a new GPO, naming it "Local Administrators GPO".
With the GPO created, I went into edit, and navigated to Computer Settings > Preferences > Control Panel Settings > Local Users and Groups.
From there I went to New > Local Group.  I selected the Administrators (built-in) group, and set the members to the local administrator account, Domain Admins, and the SCOMAA account.  I also added "MSGEEK\%ComputerName% Administrators" which will allow me to create an Active Directory group in the format "%ComputerName% Administrators" and add any accounts I like to it if I have scenarios where a specific account needs local admin access on one particular server but not domain-wide (Such as the SCOM DB account) .  By ticking Delete all member users and Delete all member Groups I can ensure that only these three accounts (or other additional ones if I modify the policy) will have full admin permissions over any Server.
With the policy created and linked to the root of the Domain, I changed the security scope from the default of authenticated users, to Domain Computers.
 I then created Active Directory security groups named "RSMSGSCSQL1 Administrators" and "RSMSGSCOM1 Administrators" and added the SCOM DB account as a member to each of these.
To check the Group Policy was working as desired, I logged onto one of the servers that didn't have an explicit administrators group and ran a gpupdate /force to verify that the 3 correct objects had been added to the local administrators group.
Next, I logged onto the SCOM SQL server, and ran this same gpupdate /force, this time I verified that there were the three expected accounts, plus the "RSMSGSCSQL1 Administrators" group I had created.
I then modified the Default Domain Controllers policy and gave the SCOMAA account permissions to log on locally.
I then opened dsa.msc and added the SCOMAA account to the Performance Monitor users group.
I then sat back for a while to let the new Group Policy take effect, and once I was happy it would be in place logged back onto the SCOM server.  From there I loaded the Computer and Device Management Wizard and selected Windows computers.
I selected automatic discovery to find all Windows-computers in the MSGEEK domain.
 I then entered the SCOMAA account that I created earlier, and clicked Discover.
The scan picked up all Domain-Joined Servers, aside from the SCOM Server itself.  I selected Agent Management Mode.
I kept the install location at it's default, and specified the SCOMAA account I created earlier for actions.
As expected for this stage, the installs succeeded for the regular Servers, but failed for the DC's.  This ensures that the Group Policy giving SCOMAA local admin over all Domain Computers is active and working.
I re-ran Discovery, and this time entered a Domain Admin account to do the actual client install on the DC's (the account will just be used this one time), and when prompted for the Action Account, set it to use the SCOMAA account again.
This time, the install succeeded.
However, looking in Device Management the two DC's are greyed out.  This is due to the need to run the hslockdown tool. 
I logged onto one of the DC's, opened a command prompt window and navigated to the SCOM\Agent folder.  Here I ran hslockdown /l, to list the current configuration, followed by hslockdown /A "NT Authority\SYSTEM" to add the local system to the allowed group.
Once that was complete, and I had repeated the same steps on the second DC, I restarted both Health services, after that Health State for all agents started showing up as good.
Finally (for now) I wanted to enable notification channels.  For now I'll just be going with SMTP. 
I pointed the server to which is in internal DNS only and (for now) points to the exchange 2003 Front-End.  Because I configured this server to accept unauthenticated email destined for valid addresses, and because any alerts I configure will only be going to addresses, there's no need to configure authentication.
I kept the default config for message format.
The four "required configuration tasks" that show up on the Operations Manager home screen had now been completed, and three of them had been removed from that home screen.  Strangely "Required: import management packs" remained, despite there obviously being a large number of management packs on there, even after a reboot.  I considered enabling all MP's just to get rid of this alert, but that seemed a little excessive, and was more likely to create more problems than the fix the this minor issue.  There are quite a few minor tweaks I still need to perform so maybe it will sort itself out when I do some of those.

No comments:

Post a Comment