PowerShell – Create-Event

This script will create an event in an existing event log or a new event log.

This can be useful to keep track of what happens in your script either locally or using monitoring tools like SCOM. You can also use it to test if custom event monitoring you’ve configured is working as expected.

Or run a task in response to a given event as explained here.

 

SCOM2012 – Extract English Only MSP Update Rollup 3 files from CAB using PowerShell (and my vision on updating using WSUS/Microsoft Update)

I created this script to automate extracting English only MSP files from CAB files in the SCOM 2012 Update Rollup 3 (UR3) files. By default it will delete extracted non-English versions. With some minor modifications it can be used for any CAB file though, not just SCOM 2012 Update Rollup 3. It includes a lot of comments, so it is manageable and can be used for getting to know PowerShell better.

SCOM 2012 Update Rollup 3 can be downloaded here : http://catalog.update.microsoft.com/v7/site/search.aspx?q=2750631

The issue with SCOM 2012 Update Rollup 3 is that after downloading you’ll end up with a total of 41 CAB files. The large number of files is because they are for different components and in multiple languages. And what is even worse, is that the file names do not show which file is for which language.This script will extract all cab files to a subfolder and will then removes the non English ones. Below are some of the example files in Update Rollup 3 to give you an idea about the nondescriptive file names:

• all-kb2750631-amd64-console_1af57997fba722cdd3dfe4b2ddb4b8d8d829dd6f.cab
• all-kb2750631-amd64-console_3d61c9e090622b2b59ee8bf7b13b922e815bdf15.cab
• all-kb2750631-amd64-console_494a77ddaa09206f8f61ecdfb2edfcd1e82a497c.cab
• all-kb2750631-amd64-console_69bb307dbd450cfd8b732c2ac3845c9870bdc6d0.cab
• all-kb2750631-amd64-console_71c65fc2ded6769edbf610958780b5a8ac374f8c.cab

Deploying SCOM 2012 components and updates to them can be done in multiple ways:                 http://technet.microsoft.com/en-us/library/hh551142.aspx

Most of the work while updating will probably be updating the agents. Basically for SCOM 2012 there are 2 major ways to install agents:

1. Push installation (initiated from SCOM 2012). Updates can then also be deployed from within SCOM (Remotely Manageable = Yes). Push installation is often preferred, because it is easy and also allows you to push updates to clients from within SCOM 2012. The downside however is that it also requires a lot of open ports (including RPC) which might not always be acceptable:                    http://support.microsoft.com/kb/2566152. Push install and update install can also consume a lot of bandwidth and depending on your architecture (b.e. WAN links), the push install might not be the best way.
2. A manual installation (anything that is not a push installation). Updates cannot be deployed from within SCOM (Remotely Manageable = No). Manual installation includes running setup manually, using a GPO software install or using deployment tools like System Center Configuration Manager). Using the GUI, you cannot simply set an agent back to remotely manageable = Yes. You can change this in SQL though, but keep in mind that connectivity  requirements still need to be met.

With Update Rollup 3, it is now possible to leverage WSUS / Microsoft Update to deploy updates (not the inital agent) to all SCOM 2012 components. I predict this will probably become the preferred way of updating SCOM 2012 for most companies:
+ It does not require many ports on your firewall to be opened.
+ Better bandwidth management (local WSUS, BranchCache, BITS).
+ Auto detects components on systems (component updates are not forgotten).
+ Still in control of when which updates are deployed/approved.
+ Leverage existing patch/update management procedures and systems WSUS/SCCM (standardization).
- Initial agent installation cannot be performed using WSUS.

PS: Also check these great blog posts when deploying Update Rollup 3:

• http://blogs.technet.com/b/stefan_stranger/archive/2012/10/22/opsmgr-2012-update-rollup-3-ships-and-my-experience-installing-it.aspx
• http://kevingreeneitblog.blogspot.nl/2012/10/scom-2012-deploying-cumulative-update.html

 

SCOM2012 – Determine OpsMgr Components File Versions Using PowerShell in SCOM2012 Agent Task

In a previous blog post I explained how to use PowerShell remoting to determine OpsMgr Components File Versions.

As an alternative you can also use a local PowerShell script. And what is even easier in my opinion, is creating an agent task. This means you can run the the script against multiple targets and show its result all from within the SCOM 2012 console.

The local PowerShell script can be found here. A management pack containing the agent task and the PowerShell script can be found here.

Based on internet info,these are the version numbers:
SCOM 2012 Cumulative Update 1 / Update Rollup 1 version = 7.0.8560.1021
SCOM 2012 Cumulative Update 2 / Update Rollup 2 version = 7.0.8560.1027
SCOM 2012 Cumulative Update 3 / Update Rollup 3 version = 7.0.8560.1036
SCOM 2012 SP1 beta = 7.0.8925.0

Thanks go out to Derek Har for his blog post that helped me to embed the PowerShell script in the SCOM 2012 management pack.

To give you an idea what the output looks like in SCOM 2012, here are some screenshots:

Bjorn_Tasks_Powershell-Get-SCOMfileversions_01

Bjorn_Tasks_Powershell-Get-SCOMfileversions_02

 

SCOM2012 – Determine OpsMgr Components File Versions Using PowerShell Remoting

We’re currently working hard on our SCOM 2012 environment. One of the things that need to be done, is upgrading the environment to the latest version, which is currently Update Rollup 3.

Two great blog posts are available to assist you in the upgrade process:

• Stefan Stranger : OpsMgr 2012: Update Rollup 3 ships, and my experience installing it
• Kevin Greene : SCOM 2012 – Deploying Cumulative Update Rollup 3 (CU3) Hotfix

Unfortunately SCOM 2012 at this moment only shows the major version 7.0.8560.0 when using get-scommanagementserver or get-scomagent. For agents you can use this PowerShell command:
get-scomagent | ft computername, version, patchlist -auto
The patchlist is however not available for managementservers, which means another approach is necessary to get an overview of the upgrade status of your SCOM environment.

Since OpsMgr 2012 Update Rollup 3 is available through WSUS now for the first time, you could leverage existing WSUS reports. Depending on your environment, not all systems might be in WSUS or the systems might be using different WSUS servers.

The script I made, is based on Stefan Stranger’s blog post. The script basically works like this:

1. It queries the SCOM 2012 environment for management servers and agents.
2. It connects to each management server and agent using PowerShell remoting, locally checks file versions against the desired versions and returns the results.

The script can be found here:
http://bjornhouben-web.sharepoint.com/Lists/Scripts

Since I’m still pretty new to PowerShell scripting, any feedback is welcome so I can improve.

 

SCOM2012 – Quick test lab setup OpsMgr 2012 SP1 Beta using prepared VHD

Since I’m currently working with System Center Operations Manager 2012 (also often referred to as SCOM 2012 or OpsMgr 2012), I needed a testing environment.

Because time is precious, I want to minimize the time and effort needed to set it up. This is what I did:

1. Install and configure Hyper-V on my Windows 8 laptop.
2. Deploy a VM with Server 2012 Datacenter edition.
   Configure a static IP address.
   Configure AD DS / domain controller role.
   Configure DHCP server role.
   Configure DNS server role (if desirable, include DNS forwarder for internet DNS queries).
3. Download and extract the pre-configured SCOM 2012 SP1 beta VHD (running Server 2012 Datacenter edition). System Center 2012 SP1 adds Windows Server 2012  SQL Server 2012 Support.
4. Create a new VM for SCOM and configure it to use the downloaded pre-configured VHD.
   Configure it with sufficient virtual CPUs and memory  for the DB and the SCOM components.
5. Start the SCOM VM, and follow the onscreen instructions. NOTE: First time configuration took about 1-2 hours, but this might be related to my hardware. Still it might be smart to plan the installation.
6. Convert the Server 2012 Datacenter edition from ServerDatacenterEval to ServerDatacenter by running an elevated CMD as administrator and issuing the following command:
   DISM /online /Set-Edition:ServerDatacenter> ProductKey:<productkey> /AcceptEula
   Reboot.
7. Replace the SCOM 2012 evaluation license with your own license using Operations Manager Shell:
   Set-SCOMLicense -ProductId “yourlicensekey“
   Reboot
   Check the license using the Operations Manager Shell:
   Get-SCOMManagementGroup | ft skuforlicense, version, timeofexpiration –a
8. Shut down your SCOM 2012 VM.
9. Shut down your AD DS / domain controller VM.
10. Create a snapshot and/or export of both VM’s so you can more easily revert to a good starting point.

Also be sure to read Stefan Stranger’s blog post that goes into more detail with regards to the domain controller and automating the task for setting it up. It also includes screenshots to give you a better idea of the process.

PS: I love how Microsoft provides these pre-configured VHD’s. This has been great in the past, but now with client Hyper-V 3.0 in Windows 8 it saves me even more time because I don’t have to boot to Windows Server 2008 or Windows Server 2012 for Hyper-V.