Wednesday, 28 August 2013

System Center 2012 - Lab Setup Notes

I was looking back through my draft posts that I never got round to fully finishing the other day and found a list post with tips in that I was jotting down while rebuilding the lab just after SP1 went RTM.

Tip #1 - Server Core/Firewall
I choose to use Server 2012 Datacenter Core for the Hyper-V hosts in the cluster.  Good practice, more secure, less reboots etc etc...
However, if you're still learning the ins and outs of PowerShell as I am it can prove a challenge sometimes to tweak all of the settings just as you want them. #1 being firewall rules.

In hind sight, a group policy setting the rules before deployment would have gone a long way to help.

I also went though them and added in all the firewall rules I'd need for the various System Center and SQL components.

Tip #2 - Live Migration
Had I been physically located in the office (I got kicked out at 19:00) then moving the DC & SCVMM to the cluster might have been relatively easy.
When working remotely, connected to SCVMM it's a little more challenging, especially when SCVMM refuses to Live Migrate from the temporary Hyper-V host to the Cluster.

Remember - to Live Migrate using Shared Nothing LM, the Hyper-V hosts must all be members of the domain (I'd left the temp server in workgroup as it was only supposed to be there for a couple of hours!)

Tip #3 - VM's & Clusters
I build some virtual machines to cluster (1 SQL cluster & 1 File Server Cluster) as part of the core infrastructure.  I'd had some issues before with VM's being clustered but put it down to my old lab environment.  Well I ran into the same issue again.

Basically the cluster wizard kept timing out when trying to add the nodes to the cluster.  It would create a cluster with a single node fine showing that permissions etc were fine.

The stranger bit came when I migrated both VM nodes to the same physical host and they joined the cluster fine straight away, yet broke the cluster each time one was on a separate physical host.

I came across a TechNet forum post discussing the issue here and then reached out to Twitter.
Thankfully, Hans Vredevoort ‏@hvredevoort came back with a reply confirming I wasn't going mad.

It looks like an issue with certain NICs (I have Broadcom and Intel in my hosts).  Hans thinks that Intels work ok so when I get chance I'll drop the Broadcom from my team and try again.

Tip #4 - Deployment Order
Microsoft have an official upgrade sequencing order here but for deployment it's not so strict.  However my approach is:
  • Virtual Machine Manager (VMM)
  • App Controller
  • Configuration Manager
  • Orchestrator
  • Operations Manager
  • Service Manager
  • Data Protection Manager (DPM)
VMM goes in first, closely followed by App Controller so that I can build the Service Templates that I use for deploying the rest.



Configuration Manager next so that we can get clients out for deploying software updates/pre-reqs and inventory the systems.

Next Orchestrator and SCOM as we'll be linking them into both SCVMM and SCSM

Then Service Manager last so we can consume the information from the other components and start to build the service catalog.

Oh, I forgot DPM... meh...

Tip #4a Deployment Order - Updates
I was talking to Sam Erskine the other day and he mentioned he hit an issue when installing Update Rollup 2 for Service Manager to the Data Warehouse and wondered if I could replicate it.

Well I did.

It looks like if you do a fresh installation of SCSM SP1 and then apply Update Rollup 2 before registering the Data Warehouse, the install will fail with the error:

An error occurred while executing a custom action:_PatchMP

Easy fix, register the DW from the console and wait for management pack sync jobs to finish (This will take a while!!) and then run UR2 again for it to succeed.

Tip #5 Account Preparation
Deploying all the System Center Components requires a fair few domain accounts if you're doing it right and not just using Local System or the same account for everything.

Use my previous blog post here on Service Accounts as a starter and prepare all the accounts in advance.  Use something like KeePass to store the accounts and their passwords to make it easier for yourself during deployment.

Tip #6 SCSM Portal
9 times out of 10 after the install you'll be presented with a blank middle pane or can't even get near the portal without being prompted for credentials constantly.

Credentials - Login as a user with SharePoint farm admin rights to the portal then use the Site Settings option in the top left to edit the site permissions to grant something like Domain Users read access.


 
If the content area is blank, chances are the URL doesn't match what it expects for the webcontent.  I used a DNS alias http://ServiceDesk to point to the IP of the server hosting my SM Portal, but the webcontent URL during setup was set to the server NetBIOS address.  Same thing applies if trying to use the FQDN most times.
 
Use IIS Manager to browse to the "Service Manager Portal" site and choose "Application Settings"
 
 
Edit SMPortal_WebContentServer_URL and modify the value to reflect the URL you are trying to connect to (and which matches your certificate if using SSL!)
 
 
 
Tip # 7 Orchestrator Users Group & Cloud Services Process Pack
I went to install the Cloud Services Process Pack (CSPP) and hit an error during install that I've seen a few times and still annoys me no end.

During the install of Orchestrator you're prompted to select a group to use to control access to Orchestrator.  It defaults to a local group, but as best practice it's best to change this to a domain account (as it says on the setup wizard).

However I've seen a few times where it still insists looking for a local group with direct membership, the CSPP is a prime example of this and it's hard coded into the install.

Manually create a local group called OrchestratorUsersGroup and assign the account you're installing the CSPP with to that account, re-run the setup wizard and it will allow you to proceed with the install.

Tip #8 SCOM Product Key
All the System Center 2012 setup wizards prompt you for the key during setup to ensure they don't install in eval mode.  Some can be converted from eval to fully licensed after install but watch out for Service Manager as this can't.

SCOM however, doesn't prompt you for a key.  Licensing SCOM is done via an Operations Manager Shell PowerShell command after install.

Rather annoyingly, if you open the shell without elevation it tells you that you don't have permission to the registry.


Yet if you run the shell elevated, you get messages that you can't load the PS Modules.


Quick and dirty, in the elevated shell type the following to load the modules:

cd\
cd '.\Program Files\System Center 2012\Operations Manager\Powershell\OperationsManager'
.\Functions.ps1
.\Startup.ps1

Then use this command to set the product key:

Set-SCOMLicense -ProductId "yourlicensekey“

Success!

 

Tip #9 - Where's my Runbooks
Sometimes the web console will fail to show any runbooks or the SCSM connector will return no runbooks after a sync.

The quick fix for this is to run the following query from SQL Management Studio connected to the Orchestrator database:
TRUNCATE TABLE [Microsoft.SystemCenter.Orchestrator.Internal].AuthorizationCache

You may also find this query useful which will run a stored procedure to clear auth cache every 10 minutes if it keeps reoccuring:
EXEC [Microsoft.SystemCenter.Orchestrator.Maintenance].EnqueueRecurrentTask 'ClearAuthorizationCache'


Tip #10 - Don't Deploy a Site Role to manage.microsoft.com
When extremely tired and you've not had enough relentless at 3am, it's often not a good idea to be making configuration changes to System Center...

I accidently placed the Application Catalog Web Service Point site role on the manage.microsoft.com site server that is added to the CM console when you have an Intune connector setup.

Nothing within the console checks and stops you from doing this and to take matters worse, it won't then allow you to remove the role from the console.

However, these two lines of PowerShell run from a ConfigMgr PS Session should sort it out.

$web = Get-CMApplicationCatalogWebServicePoint
Remove-CMApplicationCatalogWebServicePoint -InputObject $web -force



 

No comments: