The KMS MP was released yesterday as announced at here but what isn't mentioned is that all supports have been dropped!! From the manual "Appendix: Reports
Reports are no longer supported within the KMS management pack."
Unfortunately if you are going to be doing a Windows 7 rollout and using KMS, you will need this pack since the older pack doesn't support Windows 7. I've sent out a few feelers to find out what's going on.
Stay tuned
Tuesday, September 22, 2009
Monday, September 21, 2009
Agents being rejected and SPN's
I had a strange occurance going on in the past week where the agents in one domain were being rejected by the gateway server. I was getting these in the gateway Opsmgr error log from all the managed agents
Event Type: Error
Event Source: OpsMgr Connector
Event Category: None
Event ID: 20002
Date: 9/21/2009
Time: 9:53:00 AM
User: N/A
Computer: xxxxxx
Description:
A device at IP xxxxxx attempted to connect but could not be authenticated, and was rejected.
and this from the gateway server
Event Type: Warning
Event Source: OpsMgr Connector
Event Category: None
Event ID: 21035
Date: 9/21/2009
Time: 9:43:29 AM
User: N/A
Computer: xxxxxxx
Description:
Registration of a SPN for this computer with the "MSOMHSvc" service class has failed with error "The remote procedure call failed and did not execute.". This may cause Kerberos authentication to or from this Health Service to fail.
Doing a google search didn't lead to much and reading about SPN's was confusing. BUT after putting in a call to trusty MS the problem came down to the fact that I had replaced my RMS with a new RMS and the server object still existed in Active Directory.
A brief background on SPN's or service principle name. This is associated with the RMS of your environment and only the RMS should have the following entries
MSOMHSvc\RMS_server_name.fqdn
MSOMHSvc\RMS_server_netbios_name
which you can get via adsiedit/properties of the object/servicePrincipalName
since both RMS objects still existed there were two of these SPN's which would respond to any management server/gateway requesting this information. So it would be hit or miss if the proper RMS was contacted or not. If you delete these entries from the old RMS object then problem solved.
OR the moral of this story - DELETE THE OLD RMS OBJECT IN AD once you replace it.
Event Type: Error
Event Source: OpsMgr Connector
Event Category: None
Event ID: 20002
Date: 9/21/2009
Time: 9:53:00 AM
User: N/A
Computer: xxxxxx
Description:
A device at IP xxxxxx attempted to connect but could not be authenticated, and was rejected.
and this from the gateway server
Event Type: Warning
Event Source: OpsMgr Connector
Event Category: None
Event ID: 21035
Date: 9/21/2009
Time: 9:43:29 AM
User: N/A
Computer: xxxxxxx
Description:
Registration of a SPN for this computer with the "MSOMHSvc" service class has failed with error "The remote procedure call failed and did not execute.". This may cause Kerberos authentication to or from this Health Service to fail.
Doing a google search didn't lead to much and reading about SPN's was confusing. BUT after putting in a call to trusty MS the problem came down to the fact that I had replaced my RMS with a new RMS and the server object still existed in Active Directory.
A brief background on SPN's or service principle name. This is associated with the RMS of your environment and only the RMS should have the following entries
MSOMHSvc\RMS_server_name.fqdn
MSOMHSvc\RMS_server_netbios_name
which you can get via adsiedit/properties of the object/servicePrincipalName
since both RMS objects still existed there were two of these SPN's which would respond to any management server/gateway requesting this information. So it would be hit or miss if the proper RMS was contacted or not. If you delete these entries from the old RMS object then problem solved.
OR the moral of this story - DELETE THE OLD RMS OBJECT IN AD once you replace it.
Friday, August 21, 2009
Service Level Dashboard for R2
So I finally got around to attempting to install Service Level Dashboard for R2 which took a little time since I needed to request an Sharepoint instance.
This install has two parts - the management pack which is a no brainer, just import it like anything and then there is an MSI. This you need to run on the sharepoint server that you will be installing on. So if you are not familiar with sharepoint or have to request it from another group send them this list of requirements
The second issue is that "application pool identity" account which was a high puller since it requires so many rights and the install fails without giving you any indication why. This account needs to have high sharepoint access thus I'm stating it is a sharepoint admin account plus the following
But not exactly like this since you'll end up with a blank page and you'll have to configure the views. If you've already installed the Exchange R2 MP then you have some nice pre-configured SLA objects to play with. If not you'll have to first configure "Service Level Tracking" under authoring/management pack objects.
I've had some issues with Service Level Tracking using the performance SLA which others on systemcentercentral.com has confirmed as well. But that will be another post.
This install has two parts - the management pack which is a no brainer, just import it like anything and then there is an MSI. This you need to run on the sharepoint server that you will be installing on. So if you are not familiar with sharepoint or have to request it from another group send them this list of requirements
- Application pool identity domain user (pretty much as sharepoint admin account)
- Sharepoint server name
- SharePoint Database Server Name
- SharePoint Session Database Name
The second issue is that "application pool identity" account which was a high puller since it requires so many rights and the install fails without giving you any indication why. This account needs to have high sharepoint access thus I'm stating it is a sharepoint admin account plus the following
- local admin rights on the server
- SA rights on the Opsmgr dataware house - it needs to create a SLDReader role and add itself to this role*
- OpsMgr Admin rights*
*These two you should be able to remove after the install is complete.
Plus make sure you login to the server using the "application pool identity" account or else you'll end up with some other random error.
With all those rights, you should be able to install the GUI and have it configure the sharepoint instance so it can finish properly and you will get something like this
But not exactly like this since you'll end up with a blank page and you'll have to configure the views. If you've already installed the Exchange R2 MP then you have some nice pre-configured SLA objects to play with. If not you'll have to first configure "Service Level Tracking" under authoring/management pack objects.
I've had some issues with Service Level Tracking using the performance SLA which others on systemcentercentral.com has confirmed as well. But that will be another post.
Tuesday, July 21, 2009
Visio Add-in for SCOM R2
One of the features that I was excited about and still kind of am was the Visio add-in for OpsMgr R2. It basically connects Visio 2007 to OpsMgr so that your exported Visio diagram of you your distributed application is an live document that will show health state. My hopes for the product was to give the application groups views into their applications without having to give them the console BUT this is not the case.
They will get this:
But here are a few good links
Edgenet video demonstrating the capabilities
MS Blog plus the download
There is another Visio add-in for Operations manager floating around out there called "System Center Operations Manager & System Center Configuration Manager Add-In" - DO NOT GET THIS ONE. It's a template that connects to Operations Manager so you have to create your views manually and won't accept your exported views. Not to mention it has an option of downloading all the objects in OpsMgr and create a template of it which will use all your resources. I won't even link to it.
They will get this:
since the stated requirements are:
- System Center Operations Manager 2007 R2 (Release Candidate) Operations console
Visio 2007 Professional SP1
Microsoft .NET Framework 3.5 SP1, available from http://go.microsoft.com/fwlink/?LinkID=131605.
Visual Studio Tools for Office system Runtime 3.0, available from http://go.microsoft.com/fwlink/?LinkId=149729
2007 Microsoft Office System Update: Redistributable Primary Interop Assemblies, available from http://go.microsoft.com/fwlink/?LinkId=72637. (Note that this is already installed if you installed Visio 2007 after some version of .Net was already installed. If Visio was installed prior to installing .Net, re-run the Visio setup to add the .NET Programmability component or install the above mentioned package.)
But here are a few good links
Edgenet video demonstrating the capabilities
MS Blog plus the download
There is another Visio add-in for Operations manager floating around out there called "System Center Operations Manager & System Center Configuration Manager Add-In" - DO NOT GET THIS ONE. It's a template that connects to Operations Manager so you have to create your views manually and won't accept your exported views. Not to mention it has an option of downloading all the objects in OpsMgr and create a template of it which will use all your resources. I won't even link to it.
Monday, July 20, 2009
Deleting Old Management Servers Issue
With the R2 upgrades, I also upgraded a couple of management servers. The MS method for removing an management server is to first delete the management server object, move the agents and then uninstall the Opsmgr. But deleting the object without first moving all the agents to another management server will get you this error
"The management server is part of the communication topology and cannot be deleted."
and this is because you still have agents and possibly agentless managed objects pointing to that management server. So the correct procedure should be
1. Move all agents to another management server
2. Move all agentless objects to another mangement server
3. Uninstall Opsmgr
4. Delete management server objects from the console Administration/Management Servers right click delete
"The management server is part of the communication topology and cannot be deleted."
and this is because you still have agents and possibly agentless managed objects pointing to that management server. So the correct procedure should be
1. Move all agents to another management server
2. Move all agentless objects to another mangement server
3. Uninstall Opsmgr
4. Delete management server objects from the console Administration/Management Servers right click delete
Friday, July 17, 2009
32 bit vs 64 bit automated install script
In my environment, we are starting to have more and more 64 bit servers which can cause agent upgrade and patching issues since OpsMgr related upgrades have separate files for each. I don't use the "repair" option in Opsmgr since it doesn't allow you to schedule the upgrades and I for one am not going to stay up till 12AM so I can upgrade the production servers.
First I created two jobs in our deployment tool to do separate 32 bit and 64 bit upgrades but that's a pain because you have to identify the servers ahead of time. I knew that there are registry keys that will distinguish between 32 bit and 64 bit so why not create a vbscript that will do that and then execute the appropriate MSI? But being a script novice, I gave this to one of my other guys here Eric H. and he cranked it out for me. Thanks Eric!
option explicit
Dim strServer : strServer = "."
Dim objShell : Set objShell = CreateObject("Wscript.Shell")
Dim strCommand : strCommand = "MsiExec.exe /uninstall {E7600A9C-6782-4221-984E-AB89C780DC2D} /qn"
objShell.Run(strCommand),1,TRUE
Dim objMsiCommand, objPath, objInstall
If Is64Bit(strServer) Then
objMsiCommand = "%WinDir%\System32\MsiExec /i "
objPath = "%WinDir%\temp"
objInstall = "\MOMAgent_R2_x64.msi /quiet USE_SETTINGS_FROM_AD=0 MANAGEMENT_GROUP=""managementgroupname"" MANAGEMENT_SERVER_DNS=fqdn_servername"
Else
objMsiCommand = "%WinDir%\System32\MsiExec /i " objPath = "%WinDir%\temp" objInstall = "\MOMAgent_r2_x86.msi /quiet USE_SETTINGS_FROM_AD=0 MANAGEMENT_GROUP="" managementgroupname"" MANAGEMENT_SERVER_DNS=fqdn_servername"
End If
Dim strCommand2 : strCommand2 = objMsiCommand & objPath & objInstall
objShell.Run(strCommand2),1,TRUE
Set objShell = Nothing
Public Function Is64Bit(strComputer)
Dim strReturnValue : strReturnValue = False
const HKEY_LOCAL_MACHINE = &H80000002
Dim strKeyPath : strKeyPath = "SOFTWARE\Wow6432Node\Microsoft\EventSystem" Dim strValueName : strValueName = "Configured"
Dim iValue
Dim oReg : Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv") oReg.GetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,iValue
If ISNull(iValue) Then
strReturnValue = False
Else
strReturnValue = True
End If
Set oReg= Nothing
Is64Bit = strReturnValue
End Function
First I created two jobs in our deployment tool to do separate 32 bit and 64 bit upgrades but that's a pain because you have to identify the servers ahead of time. I knew that there are registry keys that will distinguish between 32 bit and 64 bit so why not create a vbscript that will do that and then execute the appropriate MSI? But being a script novice, I gave this to one of my other guys here Eric H. and he cranked it out for me. Thanks Eric!
option explicit
Dim strServer : strServer = "."
Dim objShell : Set objShell = CreateObject("Wscript.Shell")
Dim strCommand : strCommand = "MsiExec.exe /uninstall {E7600A9C-6782-4221-984E-AB89C780DC2D} /qn"
objShell.Run(strCommand),1,TRUE
Dim objMsiCommand, objPath, objInstall
If Is64Bit(strServer) Then
objMsiCommand = "%WinDir%\System32\MsiExec /i "
objPath = "%WinDir%\temp"
objInstall = "\MOMAgent_R2_x64.msi /quiet USE_SETTINGS_FROM_AD=0 MANAGEMENT_GROUP=""managementgroupname"" MANAGEMENT_SERVER_DNS=fqdn_servername"
Else
objMsiCommand = "%WinDir%\System32\MsiExec /i " objPath = "%WinDir%\temp" objInstall = "\MOMAgent_r2_x86.msi /quiet USE_SETTINGS_FROM_AD=0 MANAGEMENT_GROUP="" managementgroupname"" MANAGEMENT_SERVER_DNS=fqdn_servername"
End If
Dim strCommand2 : strCommand2 = objMsiCommand & objPath & objInstall
objShell.Run(strCommand2),1,TRUE
Set objShell = Nothing
Public Function Is64Bit(strComputer)
Dim strReturnValue : strReturnValue = False
const HKEY_LOCAL_MACHINE = &H80000002
Dim strKeyPath : strKeyPath = "SOFTWARE\Wow6432Node\Microsoft\EventSystem" Dim strValueName : strValueName = "Configured"
Dim iValue
Dim oReg : Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv") oReg.GetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,iValue
If ISNull(iValue) Then
strReturnValue = False
Else
strReturnValue = True
End If
Set oReg= Nothing
Is64Bit = strReturnValue
End Function
R2 Upgrade with Reporting Upgrade Issues
This past Thursday (7/15/09) I upgraded our production OpsMgr 2007 SP1 environment to R2 with relative ease. But I did have one slight hair pulling incident in which the Reporting Server was not upgrading properly. It would go for about 10 minutes and fail and roll back. Looking at the logs, the install would tell you to look for "Value 3" which is completely useless. But if you look for the word "error" it actually told me that it was refering to the old RMS from the registry entry in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Reporting\DefaultSDKService\
Once I corrected that, I was all set. Kevin Holman's upgrade instructions was very good and if you follow it to the T, you're good to go.
Once I corrected that, I was all set. Kevin Holman's upgrade instructions was very good and if you follow it to the T, you're good to go.
First Post
Let me briefly introduce myself, I'm Julius Tancinco and I have been working with System Center Operations Manager 2007 and have gone through it's aches and pains since it's initial release in 2007. Regardless of the minor issues that I've encountered with the product, if you are a Microsoft shop, it's the best monitoring solution available to date.
I was a bit reluctant to put up a blog since OpsMgr has a pretty good cache of bloggers already and really, what do I have to offer besides regugitating what others have already said. But considering I've been working with the product for over 2 years now I think I have a few thoughts worth blogging. So follow me via RSS or whatever it is you do and get this thing going!
Subscribe to:
Posts (Atom)