Kevin Holman's OpsMgr Blog : 2008

New Base OS MP released 9-18-2009 version 6.0.6667.0 to add support for Windows Server 2008R2 and other fixes

kevinhol — Tue, 22 Sep 2009 15:40:59 GMT

As you can see from the “Changes in this update section” of the guide – this isn't just about supporting Server 2008 R2 – there are many fixes and updates, so this would be a good one to get through your testing cycles and plan for production.

Available on the catalog: http://technet.microsoft.com/en-us/opsmgr/cc539535.aspx

Changes in This Update

The September 2009 release (version 6.0.6667.0) of the Windows Server Operating System Management Pack includes the following changes:

Support for Windows Server 2008 R2, including new classes to represent Windows Server 2008 R2 systems specifically.
The intervals for some discoveries have been changed to reduce CPU usage. For details, see Objects the Windows Server Operating System Management Pack Discovers.
Added Logical Disk Fragmentation Level monitors for Windows Server 2003 and Windows Server 2008.
Disabled the following rules and monitors for Windows Server 2008 because the events needed are in Windows Server 2003 only.
- Duplicate computer name was detected
- Windows Activation State
- Disk Group Failed
- Disk Group Auto Import Failed
- Volume Not Started
- Run WMIAdap
Fixed the summary details for the Performance History (Percent Processor Time) report to indicate that the object type is Windows Server 2003 operating system rather than Windows Server 2003 processor.
Fixed the Performance History (Percent Interrupt Time) report to use a rule that targets the operating system rather than the processor.
Changed the data source for discoveries from System.Scheduler to System.Discovery.Scheduler to avoid performance issues.
Changed the Logical Disk Availability monitor to use a Run As profile with administrative privileges to enable it to run in a low-privilege environment.
Modified logical disk discovery to exclude mount points, because numerous rules use performance counters that are not applicable to mount points.
Fixed an issue in which an alert could be generated for Windows Activation too early.
Addressed an issue that was causing some discoveries to not show up correctly in the authoring section of the console.
Improved the product knowledge for the alert generated by the “A Service is Mis-configured” rule.
Fixed issue in which logical disk health check could have performance problems when run against clustered servers.
Fixed links to views in product knowledge articles.
Added Active Alerts views for Windows Server 2003 and Windows Server 2008.
Added retry logic to the "Probe Module: Is Feature Installed" module to avoid failures due to periodic time-outs.
Added a new integer property named "Size (MBytes) (Numeric)" to the Logical Disk class and updated the existing property "Size (Bytes) (String)" to clarify that it is a string. The new property can now be used in formulas and views as expected.

Make sure you also check out the new supported config statement and known issues regarding Server 2008 R2 and Windows 7 support:

http://support.microsoft.com/kb/974722

Getting SQL Admin Studio to connect to your SQL Cluster

kevinhol — Tue, 07 Apr 2009 18:04:48 GMT

I had hell yesterday figuring out what was wrong with this.

I built a new SQL 2005 cluster, on Server 2003x64, to install my SCOM R2 release candidate environment into. I used iSCSI for my cluster, and my nodes are VM guests under Hyper-V, the same basic process that I documented here: Setting up a 2 node Server 2008 failover cluster under HyperV

So – when I was all done – my SQL 2005 Admin Studio would not connect to the remote SQL clustered named instance. This was odd – because this same admin studio WILL connect fine to any of my non-named instances… which are installed on stand-alone machines.

The machine I am running SQL Admin Studio on is a new Windows 2008 Terminal Server… with the Windows 2008 firewall. I know when connecting to a named instance, we first try and establish a connection over 1433, and if it is a named instance, we will talk to the browser service, and the browser service will tell us the dynamic port that SQL has assigned to that named instance. At this point, I could “cheat” and just hard code that port, or create a SQL alias in my SQL client… but that could lead to problems down the road. I would rather solve the problem. At first I thought something was blocking 1434, but basically, what I ended up needing to do – is to allow my “program” of SQL Admin Studio to be granted access, in the Windows 2008 firewall, on the terminal server running SQL admin studio.

The path is: %ProgramFiles% (x86)\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe

Then allow the connection, any profile, and give it a name. After this – my Admin studio connected right up to the named instance.

Authoring rules for Windows 2008 events, and how to cheat

kevinhol — Wed, 25 Feb 2009 04:56:03 GMT

So…. with the introduction of Server 2008 into OpsMgr… as a monitored agent, you might need to re-evaluate some of your old rules.

Almost all (if not all) of the basic event ID’s and parameters, in the security event log, have changed.

For instance, I had a rule to alert me on every RDP logon to every server in my lab. I did this on Server 2003, using the following data source configuration:

The logon event was 528, I used the Security event source (not really required in this case) and then I only wanted to alert on RDP/Console logon types… so that is where Parameter 4 came in. I had to use LogParser to figure out which parameter is which, and talked about how to do that in these posts:

Using Event Description as criteria for a rule

How to find all possible event ID’s for a given event source

Using OpsMgr to see which servers have not been logged on to via RDP

Now – I realized, since I rebuilt my main Terminal Server with Server 2008, this rule isnt alerting anymore.

It is apparent that the new security event is now this:

So – off I go to update my rule.

I will use Event ID 4624, that part is easy…. but now – which parameter is the logon type of “10” now?

I can certainly use LogParser… and it will tell me, but in Server 2008 – there appears to be a shortcut: Choose the Details Tab of the event you want, and all the parameters are listed, in order… and you simply have to count down:

Counting down from the top – that is Parameter 9. So my new data source expression for the rule looks like this:

So – I will ONLY get alerts on those specific events. But wait – I need to customize my Alert description! I can use the same “cheat”. In my alert description – I want to state something like “Username logged on to ServerName from IPAddress”. I can get all of that right, and the parameters – right from this event:

Counting down – I can see this is parameter 6, 12, and 19. So I make my alert description look like so:

And my alert?

Perfect!

Use this method to quickly figure out which parameters you want for your rule criteria, and your alert descriptions.

UPDATE – 2-25-2009

I have to update this post – based on the comment from Raphael Burri (http://rburri.wordpress.com/)

In addition to the easy way to find out parameters in Server 2008 – he commented on an even better way to bring rich alert descriptions in… without much work.

So for this example – I will create a new rule – which will alert me when someone types a bad password while accessing my Terminal Server:

The event in question – has changed from EventID 528 on Server 2000/2003 – to EventID 4625 on Server 2008:

Now – instead of using event parameter numbers in my Alert Description – I will use the event XPath name straight from the event! Open the event… and choose the details tab. Then choose the XML view. It looks like this:

Now – to capture ANY of these “Event Data” fields… we could use parameters – counting down like the example I posted above. OR – we can simply pull the parameter name – which is given to us right from the event:

Simply use this format:

$Data/EventData/DataItem/EventData/Data[@Name='EventParameterName']$

For instance… I want my alert description for this alert to state:

(Username) typed a bad password accessing directly from computer: (computername) from IP: (IP Address)

So from above – I can simply use the “Data Names” listed in the event data:

$Data/EventData/DataItem/EventData/Data[@Name='TargetUserName']$

$Data/EventData/DataItem/EventData/Data[@Name='WorkstationName']$

$Data/EventData/DataItem/EventData/Data[@Name='IpAddress']$

My alert description now looks like this:

The alert comes in as:

Thanks for the tip Raphael!

Recording a web application browser session driving you crazy?

kevinhol — Sat, 15 Nov 2008 20:23:38 GMT

Sometimes - getting this to work is frustrating. The problems generally are caused by the security hardening of the OS hosting the console... not an issue with OpsMgr. Here are some tips.

This is seen especially on hardened versions of Vista and Server 2008. Internet Explorer Enhanced Security Configration, and UAC (User Account Control) can cause your web recording session to be less than stellar. All of this can be configured - however, to allow the recorder to work perfectly. Lets walk through the challenges:

The first time you run this wizard - and start a capture - you will see the following popup:

Since the recorder pane is a browser extension - we need to enable this capability, which is disabled by default on many hardened browsers. Just open IE, tools, Internet Options, Advanced Tab, and check the box to "Enable Third Party Browser Extensions"

Easy enough.... However - now when we launch the recorder - we don't see a recorder bar where we should - we just see a blank pane where it would be:

This is caused by UAC (User Account control). This is enabled on Windows Server 2008 and Vista by default. Your options are to run the console "As An Administrator" or just turn off UAC altogether on the OS. Since we dont recommend disabling UAC... I am going to just close the console, then run the console "As an Administrator"

Now - we can see the web recorder add-in, as expected.

Note - this *might* RESET your browser settings - so once more - you might have to open IE - and enable 3rd party browser extensions.

HOWEVER - once we start recording - we hit another snag.... we get constantly prompted about IE Enhanced Security. You have to turn this off in order to browse any website that isnt explicitly trusted.

So... lets disable IE ESC... you can do this from server manager in Windows 2008:

I am going to turn it OFF for Administrators.

Note - this *might* RESET your browser settings - so once more - you might have to open IE - and enable 3rd party browser extensions.

Ahhhh.... IE ESC is disabled... UAC is disabled (or console is run as an Administrator) and all is well:

You basically have two options here....

1. Run the console on the server. You must disable IE ESC hardening, and work around UAC security.

2. (Recommended) Run the console on a less secured workstation, that does not have IE ESC hardening enabled, and does not have UAC enabled. If UAC is enabled on the workstation (Vista) then run the console "As an Administrator)

**** NOTE:

One thing that has been found in the field…. if you do a fresh install of the console, the web recorder wont always come up, even after checking all these configuration settings, even on older systems like 2003 and XP. You need to do a reboot of the box, in order to use the web recorder, sometimes.

Setting up a 2 node Server 2008 failover cluster under HyperV

kevinhol — Mon, 20 Oct 2008 05:11:26 GMT

For lab testing, we would often set up Microsoft Server 2003 2-node clusters, under virtual server 2005, in order to test OpsMgr configurations, such as clustered RMS, clustered databases, or just testing management packs on clustered applications like SQL and Exchange. Virtual Server 2005 did this quite easily, using the built in SCSI adapter which had cluster support. Here is a good write-up on setting this whole thing up:

http://www.microsoft.com/technet/prodtechnol/virtualserver/deploy/cvs2005.mspx

Enter Server 2008 and HyperV. HyperV does not include SCSI adapter support for clustering. That is antiquated technology anyway, since most companies utilize SAN or iSCSI for shared storage clustering - not direct attached SCSI anymore. This means you won't be able to migrate your virtual clusters built under Virtual Server 2005 to a HyperV host, nor will you be able to use the same process to build a new cluster under HyperV.

I am going to use this post to document building a very simple 2-node Server 2008 (virtualized guest) cluster, using a Server 2008 HyperV host server.

There is a really good blog discussing all the options out there for combining fail-over clustering with HyperV - located at:

http://blogs.technet.com/josebda/archive/2008/06/17/windows-server-2008-hyper-v-failover-clustering-options.aspx

And a great PFE blog essentially doing the same things I am documenting in this post:

http://blogs.technet.com/pfe-ireland/archive/2008/05/16/how-to-create-a-windows-server-2008-cluster-within-hyper-v-using-simulated-iscsi-storage.aspx

And of course the Microsoft step by step for building the cluster on Server 2008:

http://technet.microsoft.com/en-us/library/cc731844.aspx

We will be using something similar to Options 4 and 5 in the above blog post... Only one physical HyperV host, and that same host will serve as the iSCSI target. My post assumes there is already a domain present.

The BIG challenge out there - is picking an iSCSI target to use, for labs, testing, and demos. You have a lot of choices out there... Microsoft Windows Storage Server, and then other third party products.... but in the "free" space... your choices are very limited. There are some free ones out there, but few are supported by Server 2008 fail-over clustering. Best thing is to use an existing in-house iSCSI target - if you have one. If not - then people have reported success using the latest "trial" version of iSCSI target from Starwind http://www.rocketdivision.com/wind.html. I will be using an internal-only version of the Microsoft iSCSI target... cause it's free to me, and doesn't expire. :-)

Here is a high level overview of the process:

1. Setup your Server 2008 HyperV host.

2. Setup two Server 2008 guest OS's.

3. Setup a Microsoft iSCSI target on the HyperV host.

4. Connect the guest OS's to the iSCSI target

5. Setup Microsoft Failover clustering

6. Test the cluster

7. Install the cluster aware application (SCOM, Exchange, SQL, etc...)

Ok - lets get started!

I am going to make some assumptions here - to save time and not detail every part of setting up HyperV on the host, or the guests:

I have a single physical HyperV host, with a name of VS3 (Server 2008 x64). I have a single physical Domain Controller, DC1 (Server 2003 x86). My domain is OPSMGR.NET in this case. I create two guest machines - both Server 2008 x64 Enterprise. Their names will be OMCL1 and OMCL2. These will be my cluster nodes, and they are joined to OPSMGR.NET.

We need to some some quick planning for the cluster... we will need a few things.

Names:

OMCL1 - node 1 name

OMCL2 - node 2 name

OMCLV1 - virtual cluster quorum network name

OMCLSQLV1 ands V2 - virtual cluster server network name(s) for the clustered application instance(s)

VS3 - HyperV host and iSCSI target

IP address:

OMCL1

primary NIC - 10.10.10.50/16

cluster private NIC - 192.168.1.1/24

iSCSI NIC - 192.168.2.10/24

OMCL2

primary NIC - 10.10.10.51

cluster private NIC - 192.168.1.2/24

iSCSI NIC - 192.168.2.11/24

OMCLV1 - 10.10.10.52/16

OMCLSQLV1 - 10.10.10.53/16

OMCLSQLV2 - 10.10.10.53/16

VS3

primary NIC - 10.10.10.12/16

iSCSI NIC - 192.168.2.1/24

Cluster Disks:

Q: quorum

Virtual Networks:

External - External network connected to physical NIC of hyperV host - I use this for all VM and host communications.

Private - Private VM network for cluster heartbeat communication only.

iSCSI - Internal Only network that allows communications for HyperV guest OS and host only.

At this point, I have completed steps 1 and 2.... I installed hyper V, set up the networks required, added virtual network adapters for each network, made sure I can ping all devices (I had to adjust some of the Windows firewall settings on the host to get this working) but essentially - each guest should be able to ping all the other guest and host network interfaces - external, private, and iSCSI.

Then - I installed the iSCSI target - and created a 2GB shared virtual disk file on the host. I set this to allow the two Cluster node initiators by IP address.

Next, on the cluster nodes, I used the MS iSCSI initiator - connected to the host portal, and then connected to the iSCSI disks. Each node connected to the same disk, and I set the drive letters as "Q" on each. One node initialized and formatted the disk.

So I find myself at step 5. Following http://technet.microsoft.com/en-us/library/cc731844.aspx I installed the failover clustering feature on each node, then ran the cluster validation test. Everything passed except warnings from Active directory. This is because I am running my installs using a domain user account with local admin priv on the cluster nodes, but not as a domain admin. I do this on purpose... too many times Microsoft people test everything using a Domain admin account, and dont experience the same pain that our customers do in the field.... this warning was simply stating that the user running setup for the cluster, does not have permissions to create the computer accounts in the domain for the virtual cluster name. Therefore, I will create this manually using my domain admin account, and assign full control permission on the computer account object to my user account doing the cluster installs. Lastly - I need to set the computer account to "disabled" in ADUC.

Ok - now that is done - we will "Create a Cluster". Give the wizard the cluster virtual name, the the IP address we assigned as above, and click Next.

HOLY CRAP. Creating clusters in Server 2008 just got a LOT easier than doing this in Windows Server 2003!!!!

The next step is to manage the cluster, go to Networks, and set the iSCSI network properties to "Do not allow the cluster to use this network". You can also rename the 3 networks to more friendly names at this point.

At this point - you have a functioning cluster.

You should test this by making sure you can ping the virtual cluster resource name, and fail the cluster disk over to each node (stop cluster service or reboot each node)

Now - I am going to add my disks and install SQL 2005. For my SQL cluster - I have created 4 virtual disks on my iSCSI target host. 2 disks are 20GB and 2 disks are 10GB. Each 20GB disk will be for databases, each 10GB disk will be for transaction logs. Then I will install two instances of SQL 2005, and make this a multi-instance (Active/Active) cluster. First - I will connect to the disks with the iSCSI initiator, then bring them online in Disk management, then initialize them, then format them. Then - using the Cluster Management tool, add them to the cluster, and assign them the appropriate drive letters in the cluster admin tool.

From my reading - this is a lot tougher to get going - we will see.

Here is a list of known issues to be familiar with:

http://support.microsoft.com/kb/936302/en-us

http://support.microsoft.com/kb/948208/en-us

To start, I want to list some good resources on understanding clustering, and then adding SQL 2005 to a cluster.

First - a guide on installing a cluster to prepare for SQL clustering (this is Server 2003 based, however, but good tips and make sure you understand this)

http://www.sql-server-performance.com/articles/clustering/cluster_server_2003_p1.aspx

Next, a step-by-step on installing SQL 2005 to a Server 2003 Cluster:

http://www.sql-server-performance.com/articles/clustering/cluster_sql_server_2005_p1.aspx

Background data on SQL clustering:

http://www.sql-server-performance.com/articles/clustering/Cluster_Setup_and_Troubleshooting_Techniques_PartI_p1.aspx

http://www.sql-server-performance.com/articles/clustering/clustering_best_practices_p1.aspx

Here is a GREAT step by step video, of installing SQL 2005 on a 2008 failover cluster, done by a fellow PFE:

http://support.microsoft.com/default.aspx/kb/953170/en-us

OK - because I don't want to deal with the issues defined in http://support.microsoft.com/kb/932897/ I need to create my Cluster Application group manually, and add my disks there. I will create a SQL group for each instance.... naming them the same as my network names will be, to keep it simple. So I create two "Empty Service or Application" groups, naming them OMCLSQLV1 and OMCLSQLV2

Now my cluster config looks like this:

And now my storage looks like this, with a DB and LOG volume for each :

So I make sure all resources are running on OMCL1, and then pop in the SQL 2005 Enterprise x64 CD into my VM. When setup runs the pre-req check - it runs against OMCL1 and OMCL2 - so that is a good start! On the components screen - I am able to check the box "Create a SQL Server failover cluster" so that means that SQL setup detected my cluster. Great news!

I choose a named instance of SQL (inst1) and then give it my virtual server name I want to use (OMCLSQLV1). Basically just fill in each page of the setup wizard from there.... entering the IP address, choosing the correct cluster disk for your data files, picking your domain groups for cluster services, etc....

Oddly enough - it all installed really well! I did run into the issue noted in Problem 5, at http://support.microsoft.com/kb/936302/en-us which basically tells me I need to get SQL 2005 SP2 installed ASAP. I now have a fully functioning SQL 2005 failover cluster on Server 2008 x64. I then will install another SQL instance for the A/A configuration I want, and will apply SQL SP2 to both instances. Then, take a look at the OpsMgr console... and see what it discovers!

Update - Interestingly enough.... before I could event complete the installs... I got an alert about service pack compliance from OMSQLV1\INST1 which means I have already discovered SQL and started monitoring it! Even though we dont have a Server 2008 Failover clustering MP yet... it does appear the current SQL MP detects and and discovers SQL 2005 on a Server 2008 failover cluster.

Update - I could not connect to my SQL servers from the network. The SQL 2005 install is not SQL 2008 Firewall aware - therefore it does not configure the firewall to allow for SQL server access. You can read up on this subject at the following links:

http://blogs.msdn.com/sqlsecurity/archive/2008/07/01/sql-server-and-the-windows-server-2008-firewall.aspx

http://msdn.microsoft.com/en-us/library/cc646023.aspx#BKMK_dynamic_ports

Essentially - I had to create and enable three rules on each node for SQL server - A program based rule for sqlserver.exe for each instance of SQL, and then a rule opening 1434_UDP for the SQL browser service. Then, I could connect to the SQL server using simply OMCLSQLV1\INST1. If I did not open the ports for the browser service - then my application would need to know the port that the named instance of SQL was using, and connect directly with the port in the connection string. Some choose to lock down a named instance to a static port, then set up connection strings to include the fixed port... but I did not choose that route.

Update - one last note.... one of the things I typically do in SQL security, to mirror my customer environments, is to add a global group with my admin account having SA access to SQL, and then I remove BUILTIN\Administrators, and NT AUTHORITY\SYSTEM (local system account). When you did this on a SQL 2005 clustered instance under Windows 2003, you needed to add the cluster domain service account to have access to SQL, or the resource would fail to come online. Well, not in Server 2008 failover clustering - we dont use a domain service account for the cluster, it apparently uses local system, as the cluster service runs under local system. What I found was - if I follow my standard, and remove local system, the cluster resource for SQL fails. I had to go and start sql from an elevated command line on the node: "sqlservr.exe -c -s INST1", connect in SQL mgmt studio, and add the NT AUTHORITY\SYSTEM back. It did not need SA, but did need public. Once this was done the SQL resource would come online and all was well again.

How to install IIS on Server 2008 to support OpsMgr Web Console and Reporting

kevinhol — Fri, 26 Sep 2008 02:17:41 GMT

The IIS role on Server 2008 is required for Web Console support, and SQL reporting. Below are the steps to have a IIS configuration with all the options that are necessary:

On the server, run Server Manager

Click Roles, then Add Roles. Click Next.

On the Select Server Roles screen - select Web Server (IIS). Click Next.

Click Next.

On the Select Roles Services screen - add the following check boxes:

HTTP Redirection
ASP.NET (add the required additional roles)
ASP
Basic Authentication (if using Forms Based auth and SSL)
Windows Authentication (if using Windows account authorization)
IIS 6 Management Compatibility (adds all sub-roles)

Click Next. Click Install.

Installing the Web Console on a 2008 Management Server - using Windows Authentication

kevinhol — Wed, 24 Sep 2008 21:53:22 GMT

Below is a step by step on taking a Windows 2008 Management Server, and adding the Web Console... with the requirement of using Windows authentication. The easiest method is to use Forms Based auth for Web Console servers.... but using Windows Auth is possible if you can leverage constrained delegation (more on this later).

I will start by running setup, and checking the prerequisites for the web console:

We need to add the Web Server Role, and make sure we include all required sub roles. This is documented here:

http://blogs.technet.com/kevinholman/archive/2008/09/26/how-to-install-iis-on-server-2008-to-support-opsmgr-web-console-and-reporting.aspx

Once IIS is installed correctly - now run the pre-requisite check again:

All good. At this point - we can run SetupOM.exe, and add the web console component.

We will choose Windows Authentication for this exercise.

Setup should complete. If you get an error here.... you might need to open a case with Microsoft... as some hotfixes can possibly block additional OpsMgr roles from being added, such as the web console. I have 951380, 954049, and 956240 installed. I was not able to add the web console.... due to the following error:

Error 1334.The file File196.2FD07918_9082_437D_99BC_FD43602A4625 cannot be installed because the file cannot be found in cabinet file Data.Cab. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package.
MSI (s) (00:84) [12:38:44:863]: Product: System Center Operations Manager 2007 -- Error 1334.The file File196.2FD07918_9082_437D_99BC_FD43602A4625 cannot be installed because the file cannot be found in cabinet file Data.Cab. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package.

If you are affected by this.... (common also when hotfixes wont apply) we need to do a little work in the registry.... open up HKCR\Installer\Products\DF6E5EFF035E66C49971553D96AA0E4D\Patches

Back this key up by exporting it first.... once backed up... delete the REG_SZ GUIDS, and then open the "Patches" REG_MULTI_SZ key, and delete all guids from there. When done - it should look like so:

****Note: If you are running a OpsMgr management group that was originally installed as RTM, then upgraded to SP1 - you might need to leave the following guids in place in the registry when attempting to use this workaround:

727B3A3ADCF2D1945BFF1FD34105570A (this references MOM2007QFEPreSP1.msp)
8CABA70B215243145A51419A9073262F (this references MOM2007SP1.msp)

OR - I have seen these on x64:

727B3A3ADCF2D1945BFF1FD34105570A is MOM2007QFEPreSP1.msp
8817A55B3D84652468BCF9B1E587B78F is MOM2007SP1.msp

Now - rerun setup....

Ok.... When setup is complete.... one thing we need to discuss. KB 954049 is required for Server 2008 support. If you had already applied this hotfix, you must now re-apply it in order to patch the web console files in the hotfix. The simplest way is to find the MSP file for your OS version in the C:\Program Files\System Center 2007 Hotfix Utility\ folders.

And, once installed... make sure you re-import your original reg backup we took. This workaround will typically get you through a web console add, or a hotfix install.

Once that is covered - lets test the console, from the management server itself. Launch the web console from the shortcut on the start menu.

What you will likely see... is one or more security prompts asking for your username and password.... the console it trying to use Windows Auth. Once this fails, you will be presented with a forms based authentication screen.... or an error.

If you check the OpsMgr event log - you will likely see these errors:

Log Name:      Operations Manager
Source:        Web Console
Date:          9/24/2008 1:06:11 PM
Event ID:      10
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      OMMS3.opsmgr.net
Description:
Instance: 5ogbhfrszo2xqx45iw2wid45.

Error: Data Abstraction Layer: Exception while connecting to the server 'omrms.opsmgr.net'
Thread was being aborted.

This means we need to set up Kerberos constrained delegation, so that Windows Auth can work.

1. Check the SPN of the domain account used for the SDK service account. For instance... my domain is OPSMGR, my SDK Account is OPSMGR\momsdk07, and my RMS is OMRMS.opsmgr.net. I will begin... by inspecting the SPN's attached to my SDK account:

setspn /L OPSMGR\momsdk07

Results:

Registered ServicePrincipalNames for CN=momsdk07,OU=SCOM,OU=Accounts,OU=US,DC=opsmgr,DC=net:
MSOMSdkSvc/OMRMS
MSOMSdkSvc/omrms.opsmgr.net

This is good. If for any reason these are missing - we need to add the MSOMSdkSvc class SPN of the RMS computer, to the domain account used for the SDK. So in my case, this would look like:

setspn /a MSOMSdkSvc/OMRMS OPSMGR\momsdk07

setspn /a MSOMSdkSvc/OMRMSopsmgr.net OPSMGR\momsdk07

2. Verify Domain Functional Level: If you are configuring constrained delegation, you need to verify that the domain controller is operating at Windows Server 2003 functional level. (Note: This is required for constrained delegation.) Launch "Active Directory Domains and Trusts" with domain admin credentials. In the console tree, right-click the domain for which you want to verify the domain level select Properties in the context menu.

3. Verify user account options.

Open AD Users and Computers, and find the SDK account. Examine the properties, account tab, and ensure that "Account is sensitive and cannot be delegated" is NOT selected.

4. Configure constrained delegation:

In ADUC, find the computer account that the web console is installed on.

Right click it, choose properties, and select the Delegation tab.

If in a Windows Server 2003 domain, on the Delegation tab, click Trust this computer for delegation to specified services only.

And choose the Use Kerberos only radio button.

Click the Add button

In the Add Services dialogue click the Users and Computers button

In the Select Users or Computers dialogue specify the domain account that the SDK service is running under and click OK.

In the Add Services dialogue select the service type MSOMSdkSvc and click OK.

Click OK to close the Properties Dialogue. When complete - it will appear as:

Once this is complete - Constraint Delegation is set up. You might need to wait for AD replication, and might need to bounce the SDK service on the RMS for this to start working.

These constrained delegation steps work perfectly for Windows Server 2003 - however you might not be successful in Server 2008. For my Server 2008 Web Console, I had to change the Delegation option for the Web Console server, to "Trust this Computer for delegation to any service (Kerberos only)"....

What hotfixes should I apply ?

kevinhol — Sat, 13 Sep 2008 00:01:00 GMT

This topic has moved here:

http://blogs.technet.com/kevinholman/archive/2009/01/27/which-hotfixes-should-i-apply.aspx

My experience installing a SCOM Management server on Windows Server 2008

kevinhol — Tue, 05 Aug 2008 06:43:58 GMT

Figured I might as well chronicle the process.

1. First - starting off with a generic install of Server 2008 x64 Enterprise. Since this is running on Hyper-V, I installed the Hyper-V additions to make it run correctly under the hyper-v host. Gave it a static IP, joined my domain, enabled remote management so I can TS into it. I will be logging in as an account that is a member of the OpsMgr admins group, local admin on all servers, and SA over all databases.

2. Left UAC, Windows Firewall, and IE ESC enabled and in their default configurations. I added my SCOM Admins global group to the local admins group, and I explicitly added the domain SDK and management server action accounts to the local admins group.

3. Ran Windows Update and updated to all critical updates. The first batch after a clean install was 12 updates totaling 127MB as of this writing.

4. Ran the 3 required Server 2008 hot-fixes to support OpsMgr Server roles on Windows 2008: 951327 and 952664 and 953290

5. Ran OpsMgr's SetupOM.exe - and kicked off the pre-req checker. It failed:

Luckily - those are built into the OS..... so I run Server Manager, add features, and check the boxes next to .NET Framework 3.0 and Windows Powershell.

That didn't take long... now the pre-req checker again - and all greens.... so let's kick off the install.

6. During setup - I de-selected the DB and Web Console.... leaving the Management Server, User Interfaces, and Command Shell.

7. I gave it the database location, Action account, SDK account, anf joined the CEIP program. Said No to Microsoft Update and away the install goes. I *have* seen issues where customers need to run SetupOM.exe "as an Administrator" from the right click menu... so if you get an error about not being able to verify accounts - try that. I did not get that error.

8. Install was a success! I have had customers state this failed... with configuring Windows Firewall errors, but I did not get any errors.

9. A quick look at the console to make sure things look good. My new management server shows Healthy in the Administration pane of the console. No major alerts in the console with regard to the new MS. I hit the Management Server State dashboard view, and pulled up Health Explorer for the new MS. All good.

10. I spot check the new MS event log.... in the OpsMgr log... some funny business is going on..... all my agents are reporting in this log that they are not heart-beating. However - this is a new MS and no agents are even assigned to it. This could be a temporary issue, as the new configuration is becoming active. If I check all those agents in the console - they are still heart-beating just fine, and no heartbeat alerts were generated.

11. I checked the Windows Firewall configuration - and the OpsMgr install configured the firewall to open Inbound ports for access to the management server:

12. Before we add any agents on this management server - we need to get it patched up to spec with the other management servers in my environment. I currently am running 951380 and 954049.... so both will need to be applied to this management server. This is to make sure this MS is patched, and to apply the update files the the management server's \AgentManagement folder... so any subsequent agents that are push from this MS will get the updates that are consistent with my environment. I start with 951380... run the MSI - accept all defaults, then kick of the hotfix update from the installer splash screen. Then I kick off 954049 roll-up for Server 2008...

13. Another quick spot check of the OpsMgr event log... looks good. No major issues. I checked the \Health Service State folders.... we have a current OpsMgrConnector.Comfig.xml.... and it lists the RMS as the Parent, and has all my agents as Children. Good. I spot check the Management Packs folder, and I can see all my MP's have downloaded.

14. Time to move agents.... I moved them in the console... to load balance my environment.

On the new MS event log - as agents get updated config... they will move to this management server, and we will see the following type events for each agent:

Log Name:      Operations Manager
Source:        OpsMgr Connector
Date:          8/4/2008 10:33:34 PM
Event ID:      20020
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      OMMS3.opsmgr.net
Description:
The health service {33196DB1-42DB-7D62-A12F-9C6A4620CF80} running on host dc2.opsmgr.net and serving management group OPS with id {E7850522-67DF-F9E6-888A-38C99239AB74} is available.

Doesn't get much easier than this. :-)

Update....

As an afterthought... I went back and double-checked my \AgentManagement folder... and found that 951380 msp was present - but 954049 msp was missing. I did install it - and I don't think I got any errors..... the hotfix utility was there - but I could not find the MSI log from it..... I tried to reinstall it manually, by running the MSP file in the hotfix folder, but this gave a weird error.... so I just uninstalled the hotfix utilities from control panel/programs and features, and then re-ran the MSI for this hotfix. It installed just fine, and now shows up in all places. It appears that the management server did not like getting patched with 951380 and 954049 without a reboot in between - even thought they did not request or prompt for one. Oh well.

A note on KB 951116 - it is not directly required for Server 2008 support

kevinhol — Tue, 05 Aug 2008 04:53:42 GMT

If you look at the current MSKB article http://support.microsoft.com/kb/953141 on OpsMgr Server 2008 support - it states you need 4 hotfixes:

However - if you dig a little deeper.... 951116 is not required. This is because 951116 updates Advapi32.dll to version 6.0.6001.22147 on x86 and x64 servers.

If you will look at KB 953290 - you will see that it also updates Advapi32.dll, but to version 6.0.6001.22181 which is newer, and includes the updates in 951116.

In fact - if you update your server with 953290 first... and then try and apply 951116, you will get an ambiguous error that 951116 does not apply to your system.

So - bottom line.... skip 951116, and make sure you apply 953290.

Also.... 951327 is ONLY required if you plan on installing the OpsMgr console....

So MOST agents that are on Server 2008 servers will simply need to be updated with 952664 and 953290, as of this writing.

How do I know if I have all the required hotfixes on Windows Server 2008 to be supported for a OpsMgr agent?

kevinhol — Tue, 29 Jul 2008 02:58:27 GMT

Given the recent support of Server 2008 with an OpsMgr 2007 agent.... (see Announcing OpsMgr support for Windows Server 2008)

We need a good way to determine if all of our Server 2008 machines have the required hot-fixes.

We can do this by creating a Extended Class, and adding attributes to it from WMI queries. Sounds more complicated than it is. Let's get started:

In the authoring pane, create a new attribute. The name of each attribute will be the KB article number we are looking for.... and this will show up as a column in a new state view. I'll use KB951116 as the first example:

The discovery type will be "WMI Query". For the Target - we will pick "Windows Server 2008 Computer". Since this is a Class from a sealed MP - it will replace the target with the same name and add "_Extended". Lets go ahead and Name this extension with a little more detail.... so I am going to add "_QFE" to it.

Lastly - pick a Management Pack to place this extended attribute in... and name it according to your Company management pack naming standard. (you DO have a management pack naming standard - don't you???)

Namespace: root\cimv2

Query: select * from win32_quickfixengineering where HotFixID = 'KB951116'

Property Name (case sensitive): HotFixID

Frequency: 86400 seconds (1 once per day)

Click Finish.

Now - repeat the process.... for Each KB you want to see -

Give the next attribute a new name of the next KB number.

Target the new extended class this time (don't build a new extended class each time or you wont be able to see all KB's in a single view)

Modify the query for the new KB number.

When you are done - you can create a new State View - and scope it to your new Extended class

Now click the display tab - and only add the columns that make sense for this view - like the "Name" and then the KB columns:

It makes a simple view:

Now we can create a group... to show us ANY servers missing ANY required hotfixes.... and which hotfixes they need.... by targeting our new Extended class - and inserting an OR clause for all the KB's. Any missing KB's will be blank for the attribute property - so we use a "Does Not Equal" clause in this example:

Then right click the group - and show group members......

Now - we can add a new State view - and scope it to this new group:

Voila! We have a view that will only show us Server 2008 machines - and which hotfix they are missing... because it will be blank in the list.

The following pic - is missing a fake KB111111 I made up to test this:

If you desire more re-active methods.... you could write a script to alert you when a server was missing a hotfix... or even cooler - use a WMI performance Monitor to compare the queried value to what it should be... then you can have a state view and alerting based on these monitors.

Announcing OpsMgr support for Windows Server 2008

kevinhol — Mon, 28 Jul 2008 16:40:00 GMT

It's here!

First - read the overall KB article:

http://support.microsoft.com/kb/953141

You will need to download several Windows Server 2008 hotfixes, and then the OpsMgr hotfixes:

http://support.microsoft.com/kb/954049

The new supported configurations has been updated:

http://technet.microsoft.com/en-us/library/bb309428.aspx

Make sure you check out the "known issues" section to understand some of the known problems left with Server 2008 OpsMgr roles.... there will like be future hotfixes coming out to address these.

The catalog has the first batch of Server 2008 Management packs.... which include the Base OS:

http://www.microsoft.com/technet/prodtechnol/scp/opsmgr07.aspx?SCPProdID=3

MOMTEAM blog post on the new MP's:

http://blogs.technet.com/momteam/archive/2008/07/28/updated-management-packs-have-been-released-with-server-2008-support.aspx

REMEMBER - before importing ANY Management Pack - READ THE GUIDE that ships with them - there may be critical things you need to do first. When a new Native MP is replacing an older conversion MP.... you often MUST DELETE the previous old MP FIRST..... and this should be documented in the "Before importing the Management Pack" section of the guides.