(Post courtesy Rohit Kochher)
System Center Operations Manager 2012 has significant changes in setup from Operations Manager 2007. Setup of 2012 has become simpler and installation has become easier.
If you want to follow along on a test server, you can download Beta version of SCOM 2012 from here.
Note: The Root Management Server (RMS) concept which from Operations Manager 2007 R2 has been removed from Operations Manager 2012. All Operations Manager 2012 servers are management servers. However we do have an RMS emulator to support those management packs which target RMS. Architecturally, servers in Operations Manager 2012 have a peer-to-peer relationship and not a parent-child relationship like Operations Manager 2007 R2.
In this blog we will discuss the setup of Operations Manager 2012 with some screenshots of the installation wizard. Microsoft SQL Server 2008 SP1 or 2008 R2 should be installed prior running SCOM 2012 Setup. You can get more information on SCOM 2012 supported configurations here.
Now, once we run setup.exe we will see the following screen:
You can click on Install for setup of Management server, Management Console, Web server and Reporting Server. Under Optional installations you can choose to install Local agent, Audit Collection Services, Gateway management server, and ACS for Unix/Linux.
Once you click on Install you will get the screen to accept the agreement. Once you accept that you will get below screen
You can select the component that you want to install. Clicking on the arrow pointing down in front of each role will give brief information about that role. There is no explicit option to install OPS DB and data warehouse, as they are integrated. Selecting given features, you will get screen for location of program files. The default location is C:\Program Files\System Center Operations Manager 2012.
The next step will show you prerequisite failures (if any). You will get information for failures along with download links to install any missing prerequisites.
Next you get screen to input information about management server. You can specify if it is first management server in new management group or an additional management server in an existing management group.
You can specify the name of the management group here. You will also get the screen to specify operations database. We need to install both operations database and data warehouse in Operations Manager 2012. Installing Data warehouse is mandatory in 2012 (a change compared with Operations Manager 2007). The data warehouse is needed for things like dashboards etc. If this is second management server you can click on Add a management server to existing management group option.
After specifying the required information about Operations database and clicking on next, you will get similar screen for Operations manager data warehouse.
The next screen allows you to configure Operations Manager service accounts.
You can specify the required accounts on this screen and click on next to complete the setup. This setup will automatically assign local administrators group on server to the Operations Manager admin role. Once you enter account information here, it will be automatically verified in the background. In case the account cannot be verified (or the password is incorrect), you will get a red warning as the above picture illustrates.
After this, you will get the option to participate in the Microsoft Customer Experience Improvement Program (CEIP) and Error reporting. Finally, you will also get the option for configuring Microsoft Updates.
The last screen will provide you with an installation summary. Clicking on Install will start the Installation. Once finished, you are all set to monitor your infrastructure! Some of the great features in Operations Manager 2012 are the new dashboards, network monitoring , and application monitoring; which will be covered in future posts.
You can check the deployment guide for Operations Manager 2012 here.
System Center Operations Manager 2012 Beta resources
(Post courtesy Nikunj Kansara)
This post describes the network monitoring capabilities of the System Center Operations Manager 2012 Beta.
In my opinion, network monitoring is the most exciting feature of the upcoming Operations Manager 2012 release. This article will help users to get an overview of the network monitoring, how to discover network devices, configure network monitoring rules and object discoveries, sneak-peek on reports generated out of network management and network dashboard.
I have split up the blog in four different topics:
Discovery is the process of identifying network devices to be monitored.
Operations Manager 2012 can monitor devices that use SNMP v1, v2c and V3.
The benefit that we get by configuring Network Monitoring is that if a critical server seems to be down, and if network monitoring is configured, we will see an alert that a switch/router port is down which was connected to the critical server. We can also see the network topology diagram called the Network Vicinity view.
Operations Manager 2012 provides the following monitoring for discovered network devices:
Network device discovery is performed by discovery rules that you create.
Below are steps for creating the discovery rule:
1. Open the Operations Console
2. Go to Administration Workspace, right click Administration and the click Discovery
3. The What would you like to manage? Page in Figure 1 will open up and we need to select the Network Devices option and click Next.
4. The General page in Figure 2 appears and we need to provide the Name of the discovery rule and then we need select the Management server from the drop down. And then click Next.
Note: We can create one discovery rule per management server or gateway server. If we are creating a second discovery rule then we will only see the management servers that don’t have any discovery rule associated with them. Also, we might want plan ahead and strategically place the management servers or gateway servers so they can access the network devices that we would like to discover.
5. On the Discovery Method page in figure 3, we need to select the method to discover the network device. In this example we need to select Explicit discovery and then click next.
Note: Differences between Explicit discovery and Recursive Discovery: Explicit discovery – An explicit discovery rule will try to to discover the devices that you explicitly specify in the wizard by IP address or FQDN. It will only monitor those devices that it can successfully access. The rule will try to access the device by using ICMP, SNMP, or both depending on the configuration of the rule. Recursive discovery – A recursive discovery rule will attempt to discover those devices that you explicitly specify in the wizard by IP address, as well as other network devices that are connected to the specified SNMP v1 or v2 device and that the specified SNMP v1 or v2 device knows about through the device’s Address Routing Protocol (ARP) table, its IP address table, or the topology Management Information Block (MIB).
6. On the Default Account Page in Figure 4, click on the Create default Run As Account as we need to create an account which will be used to discover the network devices.
7. On the Introduction page of Create Run As account Wizard in Figure 5, click next
8. On the General Properties page of the Create Run As account Wizard in Figure 6; enter the Display name of the Run As Account and click next.
9. On the Credentials page on the Create Run As account Wizard in Figure 7, enter the SNMP community string and click on create.
Note: SNMP Community Strings We can configure Read only [RO] and Read Write [RW] SNMP Community strings. With the RO Community string we have read access to the network device. For Operations Manager 2012, we need only RO SNMP Community String to access the device. So it’s should be easy to convince the network guys ;-)
Note: SNMP Community Strings
We can configure Read only [RO] and Read Write [RW] SNMP Community strings. With the RO Community string we have read access to the network device. For Operations Manager 2012, we need only RO SNMP Community String to access the device. So it’s should be easy to convince the network guys ;-)
10. On the Default Account Page in Figure 8, select the created Run As Account and click on Next.
11. On the Devices Page, click on Add Button
12. On the Add a device window in Figure 10, enter the IP address / Name of the device we want to monitor; Select the Access Mode as ICMP and SNMP (You can also select ICMP only and SNMP only); Select the version on SNMP as v1 or v2; Select the created Run As account and then click OK.
Note: We use ICMP only in the scenario where we need to know the availability of the gateway router from the ISP to verify if the interface is up or down. We use SNMP only in the scenario where we want to monitor a Firewall on which ICMP is blocked. If we specify that a device uses both ICMP and SNMP, Operations Manager must be able to contact the device by using both methods or discovery will fail. If you specify ICMP as the only protocol to use, discovery is limited to the specified device and monitoring is limited to whether the device is online or offline.
13. Now Click Next on the Devices Page as in Figure 11.
14. On the Schedule discovery Page in Figure 12, Select the discovery schedule and click Next.
Note: You may also select to run the discovery manually.
You may also select to run the discovery manually.
15. Click Create on the Summary page
16. Click Yes on the Warning box as in Figure 14. We need to distribute the created Run As account to the Management server for discovery and to the Management Server resource pool for monitoring that was selected in General properties [Figure 2]
17. Click close on Completion.
18. Now in the Administration Workspace, go to Discovery Rules Node under the Network Management Node. You will able to see the Discovery Rule that has created. Click Run if we want to Run the discovery manually. See Figure 16
19. See the Figure 17 for the Task Status window that appears when we run the Discovery Manually. The success Status suggests that the discovery is submitted successfully and not that the devices have been discovered. Click close.
20. We will see probing status of the discovery rule when it has actually found the device. See Figure 18
21. The Discover Rule starts processing the discovered components as in Figure 19
22. The status of the discovery rule will go to pending and will run again as per the discovery schedule that we selected Wizard. If we would have selected manual discovery option in the Wizard than the status would go to Idle. See Figure 20.
23. Go to Network Devices under Network Management to see the discovered device. See Figure 21.
24. Double click the Network device to view the properties page and more information about that discovered device. See Figure 22.
B. Network Monitoring:
We will see some of the views that are relevant to the network device that we discovered in previous step.
1. Go to Monitoring Workspace; double click the Network Monitoring Folder to see the Network views. See Figure 23.
2. Select the Network Devices view to see the Network Devices being monitored.
3. Click on the Health Explorer to the Subcomponents of the Switch. See Figure 25 & 26
4. Click on the VLANs view to see the VLANs in which the switch is participating. See Figure 27
5. Click on the ICMP Ping Response Performance view or Processor utilization Performance view to see the performance graph for ping response. See Figure 28 & 29.
1. To see the connections between the connected nodes and the network device, click on the Network Vicinity view. See figure 30.
2. Click on the show computers check box to see the connections. See figure 31.
Note: By default we can see connections which are one hop away from the network device. We can select at max 5 hops. In environments with large number of network devices, selecting five hops can take a while for Operations Manager 2012 to show the data and the view might not be useful to you.
By default we can see connections which are one hop away from the network device.
We can select at max 5 hops. In environments with large number of network devices, selecting five hops can take a while for Operations Manager 2012 to show the data and the view might not be useful to you.
3. Now coming back to Network devices view in Monitoring workspace, click on the Network Node Dashboard. We will able to view all the information related to Network devices in the just one window. See figures 32, 33, 34 and 35.
D. Reporting: [See Figure 36]
Processor Utilization Report: It displays the processor utilization of a particular network device in a specified period of time.
Memory Utilization Report: It displays the percentage of free memory on a particular network device in a specified period of time.
Interface Traffic Volume Report: It displays the rate of inbound and outbound traffic that goes through the selected port or interface in a specified period of time.
Interface Error Packet Analysis Report: It displays the percentage of error packets or discarded packets, both inbound and outbound, for the selected port or interface.
Interface Packet Analysis Report: It displays the types of packets (unicast or non-unicast) that traverse the selected port or interface.
(Post courtesy Bonoshri Sarkar)
Hi everyone, this is Bonoshri Sarkar here. I have worked for Microsoft as Partner Technical Consultant specializing in Directory Services for the past two years; providing end to end consulting to enable partners to design, position, sell and deploy Microsoft Platforms for their customers. In my earlier role, I worked for more than 4 years on the Microsoft Support team focusing on Microsoft Directory Services.
Since I have a great affinity for Directory Services, I thought it would be a great idea to pen down my thoughts and experience on ensuring a smooth Active Directory Upgrade.
For any kind of Upgrade/ Migration / Transition to go smooth, and later on to have an healthy environment, it is required to spend a fair amount of time in planning and making sure that the source or the present environment is in a healthy state. Two driving factors for any upgrade or transition include the need to utilize the new features that the new version of the product has to offer, and the other being to ease the complexities and the issues of the current environment. However, most IT Pros do not take adequate steps to check the health of their existing Active Directory environment. In this post, I would like to address some of the key steps that an AD Administrator must perform prior to an upgrade or transition.
In my experience of assisting customers and partners in different transitions, most of the issues pertain to the source domain or the source domain controllers, so I will discuss few important things which should be considered as mandatory before going for any kind of Upgrade / Migration / Transition.
The health check should be done in 2 phases.
1. Planning Phase
2. Deploy Phase (just before implementing the upgrade, transition or migration)
In the first phase we should identify what all services and roles are running on the machine that we are planning to upgrade, and rule out things that we do not want to move to our new box.
Putting emphasis on diagnosing AD issues, we can use dcdiag to ensure a healthier Active Directory, I know we have been using dcdiag for many years, and we look for failure messages in the output, but apart from the failure messages, we can also consider issues such as those highlighted in yellow below:
If you notice the first part of dcdiag says “failed test replication”, which implies that there are issues with Active Directory replication with this Domain Controller.
The second message tells us that there are issues with netlogon and sysvol which are default logon shares, both the errors can be interdependent or could be because of completely different reasons.
In this scenario we need to fix AD replication first or dig into it more to find what is causing these errors. Now you can use few more commands to check the AD replication like repadmin /syncall /eAP. In case of a huge enterprise, you can also use Replmon (2003).
The third message tells us that the important services are running. We need to be sure that the above services are started to ensure a smooth transition.
If we don’t get enough details from the dcdiag results, check the event viewer, and if you do not see anything restart the FRS service and then check the event viewer for Event ID 13516.
Apart from dcdiag you can also use Netdiag to check the network status and get detailed information.
In addition to this, make sure the NIC card drivers are updated on the old server.
Instead of disabling the hardware or software based firewall between on the servers (old &new), ensure that you make the appropriate exceptions and port configurations to ensure proper communication between the directory servers (see Active Directory and Active Directory Domain Services Port Requirements).
Any third party legacy application(s) should be tested in lab environment to make sure that they are compatible with new version of server OS and Active Directory.
We also have different versions of Exchange BPA (Best Practice Analyzer) tools depending on the version of Exchange to check Exchange integrity and Exchange specific permission (You can select Permission check to gather that information).
Last but not the least read the migration or transition documents (http://technet.microsoft.com/en-us/library/cc731188(WS.10).aspx) to make sure server has all the minimum requirements.
Once we are sure that the servers are in healthy state do not forget to take a full and a system state backup using a supported backup system as documented in the TechNet article below
All these stitches in time would definitely save you nine hours’ worth of troubleshooting. It’s up to you to decide, would you like to troubleshoot or enjoy your Fries with Coke?
(Post courtesy Anil Malekani)
Recently I tried configuring Software Update Management in Configuration Manager 2012. After installing WSUS on the Configuration Manager 2012 box, I tried to install Software Update Point as a site role.
The Software Update Point role successfully installed, as per the SUPSetup.log file (under C:\Program Files\Microsoft Configuration Manager\Logs)
However, my updates still did not appear on the console. After checking the Site Component status for SMS_WSUS_SYNC_MANAGER and SMS_WSUS_CONFIGURATION_MANAGER I noticed errors as below
SMS_WSUS_SYNC_MANAGER: Message ID 6600
SMS_WSUS_CONFIGURATION_MANAGER: Message ID 6600
I checked under WCM.log (under C:\Program Files\Microsoft Configuration Manager\Logs), and found the following proxy error
SCF change notification triggered. SMS_WSUS_CONFIGURATION_MANAGER 1/1/1601 12:00:00 AM 5408 (0x1520)
This SCCM2012.CORP80.COM system is the Top Site where WSUS Server is configured to Sync from Microsoft Update (WU/MU) OR do not Sync. SMS_WSUS_CONFIGURATION_MANAGER 1/1/1601 12:00:00 AM 5408 (0x1520)
Found WSUS Admin dll of assembly version Microsoft.UpdateServices.Administration, Version=3.0.6000.273, Major Version = 0x30000, Minor Version = 0x17700111 SMS_WSUS_CONFIGURATION_MANAGER 1/1/1601 12:00:00 AM 5408 (0x1520)
Found WSUS Admin dll of assembly version Microsoft.UpdateServices.Administration, Version=3.1.6001.1, Major Version = 0x30001, Minor Version = 0x17710001 SMS_WSUS_CONFIGURATION_MANAGER 1/1/1601 12:00:00 AM 5408 (0x1520)
The installed WSUS build has the valid and supported WSUS Administration DLL assembly version (3.1.7600.226) SMS_WSUS_CONFIGURATION_MANAGER 1/1/1601 12:00:00 AM 5408 (0x1520)
System.Net.WebException: The request failed with HTTP status 502: Proxy Error ( The host was not found. ).~~ at Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer(Object args)~~ at Microsoft.UpdateServices.Administration.AdminProxy.GetUpdateServer(String serverName, Boolean useSecureConnection, Int32 portNumber)~~ at Microsoft.SystemsManagementServer.WSUS.WSUSServer.ConnectToWSUSServer(String ServerName, Boolean UseSSL, Int32 PortNumber) SMS_WSUS_CONFIGURATION_MANAGER 1/1/1601 12:00:00 AM 5408 (0x1520)
Remote configuration failed on WSUS Server. SMS_WSUS_CONFIGURATION_MANAGER 1/1/1601 12:00:00 AM 5408 (0x1520)
STATMSG: ID=6600 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_WSUS_CONFIGURATION_MANAGER" SYS=SCCM2012.corp80.com SITE=CM1 PID=2424 TID=5408 GMTDATE=Fri Oct 14 00:20:03.092 2011 ISTR0="SCCM2012.corp80.com" ISTR1="" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0 SMS_WSUS_CONFIGURATION_MANAGER 1/1/1601 12:00:00 AM 5408 (0x1520)
Waiting for changes for 46 minutes SMS_WSUS_CONFIGURATION_MANAGER 1/1/1601 12:00:00 AM 5408 (0x1520)
I validated that the proxy had been configured correctly and my browser settings also contained the same settings.
Resolution: After spending some time I found that Configuration Manager 2012 uses the system account proxy settings, which were set to Automatically detect settings.
System Center Operations Manager 2012 has some exciting features out of box like Networking Monitoring, Application monitoring and Dashboards. We will cover Dashboards in series of two blogs. In the first blog we talk about terminology of dashboards and create a performance widget. In the second blog, we will create state and alert widgets. I will be using Operations Manager 2012 Beta edition for these blogs.
The Data warehouse which (was an optional component in System Center Operations Manager 2007 R2) is now mandatory in Operations Manager 2012. The main reason for this change is dashboards.
While designing dashboards, we define two things
1) Templates: We have two types of templates. Column layout and Grid Layouts, and you specify number of cells after you select any template. These layouts specify arrangement of cells that actually host content.
2) Widgets: Once layout is created, we add widgets in the layout. In OM 2012 beta edition, we have three types of Widgets namely Alert, Performance and State. While creating widget, we define criteria to collect data from database.
To create a dashboard we will be start from from Operations Console. Choose New –> Dashboard View
We have to choose one layout out of the two available templates. We will select Grid layout and name the dashboard.
Next, we define number of cells and we choose one of the layouts.
Once the wizard is completed, you can click on Configure to change the number of cells and layout of dashboard. Also you can interchange the positions of all the widgets by using the two arrows.
Adding widgets to dashboards: You can click on “Click to Add widget” and it will start the wizard of creating widgets. In Operations Manager 2012 Beta edition we have alert, state and performance widgets.
We will start by creating a Performance widget.
We will name the widget “SQL Performance counter”, and will use this to view performance of SQL computers.
On “Specify the Scope and Counters”, select a group.
We select a group of SQL computers. Next we will select performance counters. We will define object, counter and instance.
The next step is to define Time Range.
The next step is to configure the way you would like chart and legend to display.
Finally we get our SQL Performance Widget. You can click on Configure to change scope, counters, time range, chart preferences. Also you can click on Personalize to change chart and legend to display.
You can also hover anywhere on graph to see the exact value.
In the part 2 of the series, we will create alert and state widgets.