Thursday, February 28, 2013

The FREE whitepaper, all about Service Pack 1 for System Center 2012 is NOW available for download!

This whitepaper is a joint effort between Savision and Insight24. I had the honors to write that paper which was a good experience.

Anyone working with any System Center (2012) product should read this whitepaper since it contains no marketing mumbo jumbo. It has a different angle. Instead of describing only the technology behind SP1 for System Center 2012 it focuses also on the why behind it all, like:

Why does Microsoft invest so much into System Center 2012 (SP1)?

Why did SP1 for System Center 2012 come out so soon after System Center 2012 went RTM?

And also the BIG PICTURE behind it all: of course there is a strategy behind System Center 2012 and its related SP. This strategy is also described in the same white paper.

The whitepaper can be downloaded from the website Savision and from the website of Insight24.

The book System Center 2012 Operations Manager UNLEASHED is available from today!

I co-authored this book by writing chapter 9, Complex Configurations. It was a unique experience and learned a lot from it. A BIG word of thanks to Kerrie Meyler, Cameron Fuller and John Joyner.

I already respected them but now even more. And an extra special word of thanks to Kerrie for all her patience with me. Much appreciated Kerrie and hopefully we meet at MMS 2013. If so, I’ll buy you a drink!

Paperback can be bought here(at Amazon UK) and the Kindle edition here (also Amazon UK). It seems like the Amazon.com shops aren’t updated yet, but when they are I’ll update this posting.

Some days ago Microsoft released a tool targeted at troubleshooting System Center 2012 SP1 Server-side components, System Center 2012 SP1 Configuration Analyzer. This tool is an add-on for Microsoft Baseline Configuration Analyzer 2.1.

As Microsoft describes this tool (taken directly from the related website):

‘…The System Center 2012 SP1 Configuration Analyzer is your first line of defense in troubleshooting issues with System Center 2012 SP1 server-side components. The System Center 2012 SP1 Configuration Analyzer is a diagnostic tool that you can use to evaluate important configuration settings for computers that are running any of the following System Center 2012 SP1 components: Operations Manager, Virtual Machine Manager (VMM), Service Manager, Orchestrator (plus Service Provider Foundation), Configuration Manager, and Data Protection Manager (DPM)…’

There are some things to reckon with:

The tool is an add-on for Microsoft Baseline Configuration Analyzer 2.1Basically meaning this tool has to be installed FIRST. This tool can be found here.

The download webpage states it’s version 2.0?Yes, that’s correct. It’s apparently the most current version (2/7/2013) and works with System Center 2012 SP1 Configuration Analyzer.

Error: Something about Credssp to be enabled on remote servers to check configurationsYes, the security in Windows Server 2012 is tight (don’t know whether the same issue is at play on Windows Server 2008 R2 SP1 servers) and when trying to check a remote server (the MS02) I got this error: ‘…Microsoft Baseline Configuration Analyzer 2.0 for System Center 2012 SP1 requires Credssp to be enabled on DB01 to check configurations for the module CM_CA. You must enable Credssp or run Microsoft Baseline Configuration Analyzer 2.0 from the local machine…’

Gladly, the solutions are shown as well which is a two step process:Step 01: Run this PS command on the server you’re running MBCA from: Enable-WSManCredSSP -Role Client -DelegateComputer [target machine name]

Step 02: Run this PS command on the server you’re going to scan with MBCA:Enable-WsManCredssp -Role ServerNow MBCA will run just fine.

When scanning a whole set of servers it’s better to create a GPO for those servers, saves you a lot of time, also partially explained in the same error message shown by MBCA: ‘…Use gpedit.msc and look at the following policy: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Delegating Fresh Credentials. Verify that it is enabled and configured with an SPN appropriate for the target computer. For example, for a target computer name "myserver.domain.com", the SPN can be one of the following: WSMAN/myserver.domain.com or WSMAN/*.domain.com. For more information, see the about_Remote_Troubleshooting Help topic…’

This tool can aid you when troubleshooting issues with your SC 2012 SP1 management servers. However, the good old Event Viewer still packs tons of solid information for troubleshooting as well. Combined they pack a lot of power.

Bumped into this issue with my one of my test labs. It ran SCOM 2007 R2 CU#6, was upgraded to OM12 RTM then to OM12 SP1. Afterwards the underlying Windows Server OS was upgraded to Windows Server 2012.

IssueEven though everything seemed to working just fine, OM12 SP1 Operations Manager Shell failed to work afterwards. All I got was this annoying error when trying to run it: ‘…Import-Module : The specified module 'OperationsManager' was not loaded because no valid module file was found in any module directory…’

And no matter what I did or tried, this error kept coming back biting me. Both OM12 SP1 Management Servers had the same issue. Also recreating the shortcut as stated here didn’t make any difference so it was time for another approach.

CauseSince these Management Servers were the ‘victim’ of so many upgrades (SCOM 2007 R2 > OM12 RTM > OM12 SP1 and Windows Server 2008 R2 SP1 > Windows Server 2012) I suspect something went wrong during one of those upgrades. Also because the other OM12 SP1 Management Server had the same issue as well.

SolutionI made a snapshot of both OM12 SP1 Management Servers opened Programs and Features, removed the Console and reinstalled it. Afterwards all was fine again and the OM12 SP1 Manager Shell loads and runs as expected!

Thursday, February 21, 2013

Since OM12 Management Servers do share the same functionality which was hosted originally by the RMS in SCOM 2007 (RTM/SP1/R2), it’s easy to make the OM12 Management Console high available by using Network Load Balancing.

Yes, you’ll need at least two OM12 Management Servers for it. But IMHO – based on experiences out of the field – any serious OM12 MG should have at least two OM12 Management Servers. Otherwise the Resource Pools won’t be able to function properly.

This posting is based on OM12 SP1 and Windows Server 2012. Both OM12 SP1 MS servers do have only one NIC available, so it’s important to configure the NLB Cluster for multicast. When you don’t do that and use the default setting instead (unicast) the servers might become unreachable.

There is much to tell, so let’s start.

Step 01: Installing NLB on both OM12 MS serversThis is very easy since it’s all wizard driven. Yes, it can be done by PS as well of course. In this posting however I use the GUI for it.

Open Server Manager > Manage > Add Roles and Features > a wizard kicks in now;

The NLB functionality will be installed now and soon this message will appear: Installation succeeded on <FQDN>.> Close.

Repeat these steps for the other OM12 SP1 MS server which will become part of the NLB Cluster.

Step 02: Creating a NLB ClusterNow it’s time to create the actual NLB Cluster which will be configured in such a manner that it will reroute all the OM12 SP1 Management Console traffic (TCP 5724) to one of the members of the NLB Cluster.

Again, this can be done by PS, but I have configured it all by using the GUI.

Click right on Network Load Balancing Clusters and select New Cluster;

Enter the name of the first server which is going to be part of this new NLB Cluster > Connect;

Now the available interfaces will be shown. Select the interface you’re going to use for this NLB Cluster > Next

This screen doesn’t require any modifications > Next;

> Add

Enter the IPv4 address that’s going to be used by the NLB Cluster. I used an IPv4 address in a range outside the IP addresses I use normally for my servers, so it’s easier to differentiate;Enter the subnet mask > OK. The screen looks like this now:> Next;

Enter the FQDN of the NLB Cluster. In this example I used OM12Console.sc.local. Also select the option Multicast. With servers using a single NIC selecting Unicast will most likely render them inaccessible over the network… > Next;

Now the Port Rules are shown. By default one Port Rule is added but requires some additional attention. Otherwise NLB won’t work as expected…> Edit > unselect All so only the IPv4 address of the NLB Cluster is shown;> modify Port range to 5724, used by the OM12 Management Console connection;> Set Protocols to TCP only;> Set Affinity to None;Now your screen should look like this:> OK > Finish.

Now the NLB Cluster will be created and the first NLB node added to it. This might take a few minutes and during this time your network connection will bounce a few times. But when the NLB Cluster is configured properly, the connection will be OK again;

In the Network Load Balancing Manager screen the progress will be shown, when all is OK you should see something similar to this:

In the same screen you’ll see also this:So you know for sure the NLB Cluster is OK and the first NLB node is up & running!

Before we add the second OM12 SP1 MS server to the NLB Cluster we’re going to do something else first: adding a new Host record on our DNS server so the IPv4 address is properly resolved.

Step 03: Creating a proper Host (A or AAA) record for the NLB ClusterThis is easy as well. Open the DNS snap-in and simply add a host record for the NLB Cluster. In this case the name is OM12Console(sc.local will be added automatically) and the IPv4 address is 192.168.137.200:

Before we add the second OM12 SP1 MS server to the NLB Cluster, it’s better to test the functionality of the NLB Cluster first. When only one NLB node is added, it’s easier to troubleshoot.

When all is well you should see a black cmd-prompt screen, basically telling you the NLB Cluster is up and running and handling OM12 SP1 Management Console connections!

Step 05: Adding the second OM12 SP1 MS server to the NLB ClusterYeah, I know, finally! But at least we know by now all is working as intended, which is very important.

In Network Load Balancing Manager right click on the NLB Cluster you created earlier in Step 02 > Add Host to Cluster;

Enter the name of the second OM12 SP1 MS server you want to add to the NLB Cluster > Connect > select the interface you want to use for the NLB Cluster > Next;

Don’t modify anything in this screen > Next;

The Port Rules are good as they are, so no modification required > Finish;

Now the second OM12 SP1 MS server will be added to the NLB Cluster. Again this can take some minutes and during this time your network connection will bounce a few times. But when the NLB Cluster is configured properly, the connection will be OK again;

In the Network Load Balancing Manager screen the progress will be shown, when all is OK you should see something similar to this:

In the same screen you’ll see also this:So you know for sure the whole NLB Cluster is OK and the both NLB nodes are up & running!

Step 06: The Real WordSo now we have our NLB Cluster in place. Let’s test it with the OM12 SP1 Management Console.

Start the OM12 SP1 Management Console. By default it will connect to the OM12 SP1 MS server it connected to the last time;

In the OM12 SP1 Management Console go to Tools > Connect;

Enter the FQDN of the NLB Cluster in the Server name box > Connect;

Since it’s the first time this connection is used it will take a few seconds extra, so be patient. But soon enough you’ll see this in the left bottom of the OM12 SP1 Management Console:

And then you’ll see this:

Three tests to see it’s really working:

Open a cmd-prompt, enter this command: netstat <enter>. Scroll through the list and you’ll see an entry like this:

In the OM12 SP1 Management Console go to Tools > ConnectYou’ll see the Recent Connections(only the successful connections will be shown here!) and among them the FQDN of the NLB Cluster will be shown!

The REAL TEST:

Open an OM12 SP1 Management Console on a system which isn’t an OM12 SP1 MS server;

Connect the Console to the FQDN of the NLB Cluster;

When the connection is made and the Console is working, look for EventID 26328, source OpsMgr SDK Service in the OpsMgr event logs of the OM12 SP1 MS servers in order to know to what OM12 SP1 MS server the Console is connected to;

Stop the Data Access service(System Center Data Access Service) on that server and set it (temporarily!) to Manual so OM12 won’t start it for you;

Go back to the OM12 SP1 Management Console. It will throw a SDK error;

After a minute or so the OM12 SP1 Management Console will continue working since it’s reconnected to the other node of the NLB Cluster. Test it by clicking on any View in the Console;

In order to check it, look for EventID 26328, source OpsMgr SDK Service in the OpsMgr event log of the OM12 SP1 MS which is the node of the NLB Cluster with the running Data Access service.

Don’t forget to start the Data Access service again on the OM12 SP1 MS server where you stopped it previously (Step 3.4) and set it to start Automatically again.

RecapConfiguring NLB for the OM12 Management Console isn’t hard at all and will make your OM12 environment even more robust, without making huge investments. One thing to reckon with though: in this posting I used servers with only one NIC. In real life it’s better to use a dedicated NIC for it.

Wednesday, February 20, 2013

Got this request from a reader of my blog to provide the (high level) steps for migrating from SCOM 2007 R2 CU#4 (or higher) to OM12 SP1 when running Windows Server 2003 and SQL Server 2005.

Since I am very busy these weeks I don’t have the time to go through all the required steps in detail. Luckily I have written many postings touching these steps. So I will describe the required steps in a high level in this posting, referring to the relevant postings. There is much to tell, so let’s start.

First things first: tAP or upgrade?So you have a SCOM 2007 R2 CU#4 (or higher CU# level) in place and want to migrate to OM12 SP1? However, the migration is a bit more complex since the SCOM 2007 R2 servers (RMS, MS server(s) and even perhaps Gateway Server(s) run on Windows Server 2003 and use SQL Server 2005 for the related databases and reporting functionality.

In cases like these there are two valid approaches: either you start all over with a brand new OM12 SP1 environment and phase out the current SCOM 2007 R2 environment step by step, or you upgrade the SCOM 2007 R2 environment to Windows Server 2008 R2 SP1 x64 and SQL Server 2008 R2 SP1 first before upgrading it to OM12.

Per situation it’s a hard decision to make. Read this posting of mine, al about tAP(the Alternative Approach) and write yourself a business plan. Of course not in all details but at least covering the costs involved, required resources and time.

Like any other migration/upgrade, preparation is KEY. So prepare yourself…

Upgrade it is…OK, so the decision is made, based on objective information and an upgrade it will be. These are the steps to follow.

Upgrade to Windows Server 2008 R2 SP1 x64This is required for all SCOM 2007 R2 server roles (RMS, MS server(s) and Gateway(s)). Best approach here is to introduce new servers (VMs are most preferred) and make them MS servers first (even when that server has to replace the current RMS). Of course for Gateway Servers, you make them Gateway Servers, not MS servers .

When those new MS and Gateway servers run perfect and have no issues at all, it’s time to move them into production. Basically meaning the current MS servers are replaced by the new ones. Don’t touch the RMS yet! So the new MS servers, based on Windows Server 2008 R2 SP1 x64, will take over the monitoring functionalities of the current ones. Don’t forget about third party software like Savision, Veeam and Jalasoft for instance! The require special care and planning as well.

When that’s all OK, keep the old MS servers running for a couple of days so there is always a fall back. When SCOM is still running like clock work, you can remove them (one by one!) from SCOM 2007 R2.

Make sure though to test this scenario (promoting a MS to RMS and demoting an old one) in a test environment. This way you’re familiar with it!

For your Gateway Servers, simply use them as the new ones and uninstall the old ones. Sometimes it’s a challenge to make the Agents communicate with the new Gateway Server when those Agents are manually installed…

Upgrade to SQL Server 2008 R2This one is a challenge. Simply because SCOM 2007 R2 Reporting can be a pain in the b#ckside. My personal lessons learned are simply to remove SCOM 2007 R2 reporting temporarily and reinstall it on the new SQL Server 2008 R2 SP1.

Another challenge might be the customized Reports. Also prepping the new SQL Server(s) with the correct security settings, CLR enabled and so on can be a challenge.

Veeam

NiCE

Search This Blog

Didacticum

Pageviews last month

Visitors to this blog:

Why this blog?

On an almost daily basis I work with Azure, OMS & System Center related technologies. At the moment my main focus areas are Azure, OMS, SCOM & SCCM.

Because I bump into many challenges I decided to start this blog, which has two main purposes: to help YOU with mastering these products by covering the undocumented features and last, but not least, as my personal - but open to any one - knowledge base.

From January 2010 on I have been rewarded with the MVP award and until now this this status is prolonged every year.

MVP AWARD

Follow me on Twitter

Disclaimer

The information in this blog is provided 'AS IS' with no warranties and confers no rights. This blog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my own personal opinion. All code samples are provided 'AS IS' without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.