Shared posts

09 Oct 22:04

Orchestrator 2012: Parallel reboot of server groups

by opsmgrtipps

As stated in my post “Orchestrator 2012: Patch a server with SCCM 2012” we had a request to reboot and patch groups of servers in parallel. The requirements were: Restart servers from different groups parallel, manual or scheduled start, do not go on with the rest of the servers in a group if one fails in this group.

How can we do that? First of all: use System Center Orchestrator 2012 – the automation tool from Microsoft.

Then I use SQL to provide the server names and store the status of the process.

I have a OrchestratorTemp database with two tables in there (plus the table described for the patching – see my blog):

ServerStatus:
ServerStatus

Service:
Service

The ServerStatus table has some entries already filled, when the runbook starts:
Servername, Grouping.

The Grouping had the values “OWA” and “General”. So servers of these two groups can be rebooted in parallel.

The start workflow looks like this:

startsite

It has to be started with the following parameter: Patch = Yes/No. This defines if patches should be applied or not.

If you need to schedule the reboots then you can add a schedule runbook in front of it which checks the date and initializes this runbook with the required start parameter.

It initiates the “Start groups” runbook and waits for completion. After the reboots it checks the patch status, checks the overall status and empties the tables (in the server status table it only deletes the fields which show the status).

Start Groups

This runbook enables the parallelity and can be extended with more groups.

startgroups
The “Get Server Groups” activity runs the following query: Select Distinct Grouping from dbo.ServerStatus.

The output will be used to start the “Control” runbook and fill the parameter “Grouping”. The parameter “Patch” is also provided to the sub runbook.  

Control
control

This runbook helps to ensure that the rest of the servers in a group are skipped if one server fails.
It has a “Job concurrency” of the number of groups.

Details:

  • “Get failed Server in Group” : Select Servername from dbo.ServerStatus where Grouping =’%Grouping%’ AND Status = ‘Failed’
  • “Get next Server in Group” : Select Top 1 Servername from dbo.ServerStatus where Grouping =’%Grouping%’ AND Status is NULL.
  • When it found a server then it initiates the “Maintenance” runbook with the parameters: “Servername”,”Patch” and “Group”. It waits for completion.

Maintenance

This is the main reboot runbook. It could be split up to multiple sub runbooks, but I only took the patching part out of it. It can also be extended with pre or post activities to stop services or do other tasks around the reboot.
This runbook has a “Job concurrency” of the number of parallel groups.

maintenance

The easiest way to follow this workflow is to go straight from top to down. The enties in on the left and right are only for logging.

The main things this workflow is doing are: ping the computer, start SCOM maintenance mode, install patches, reboot, check netlogon service to see that the system is up, check patch status, check services and restart if necessary, check general service status, stop maintenance. Additionally it logs the status of the steps and sends out emails.

Here are the details of the non standard activities:

  • Get NetLogon Service Status: This is a “Run Command” activity running on the local on the runbook server. sc \\%Servername% query netlogon
  • Get Citrix Services: This is a “Run .Net” activity to get application specific services – here for Citrix. It runs a PowerShell script  and publishes the variable “output” :
    $output=@()
    $services = get-wmiobject win32_service -computername %Servername% | where {($_.displayname -like ‘*Citrix*’) -and ($_.Startmode -eq ‘Auto’)}
    foreach ($service in $services)
    {
    $output+=$service.displayname
    }
  • The Get-FQDN activity is described here.

Neil Peterson has written also a complex runbook about patching a Hyper-V cluster. He used some other methods to intialize the patching and presented the whole process on the MMS2013. You can get the details and watch the session here: http://blogs.technet.com/b/neilp/archive/2013/04/15/mms2013-session-now-on-channel-9-patching-a-hyper-v-cluster-with-orchestrator-configuration-manager-including-downloadable-runbook-exports.aspx

The Runbooks can be downloaded here.


09 Oct 22:04

Orchestrator 2012: Patch a server with SCCM 2012

by opsmgrtipps

You will perhaps have the question in your mind “Why initialize patching with Orchestrator?”.

We had the request to restart and patch servers on a reoccuring schedule in groups and with pre and post tasks to check. You can do that all in SCCM 2012 through tasks sequences, but Can you also control that SCCM should stop when one of the servers in the group fails and that you get a status at the end? Orchestrator can do that. It can run some general tasks for all servers or special tasks for single servers, so you can control more in there.

I will also create another blog post to describe the reboot runbooks. Here I want to focus on the patching part. This can also separately be initialized outside of the reboot process.

For our reboot szenario we only wanted to check which patches are available. Install them, reboot and after the reboot check which patches are installed successfully and if there are additional missing patches. We did not install those then. You could extend that as you need it.

We use System Center Orchestrator 2012 SP1. For my runbook I do not use the System Center Configuration Manager 2012 SP1 integration pack. I only use WMI queries to check which patches are available. But you still need SCCM 2012 to deploy the patches!

I use the following WMI classes:

CCM_SoftwareUpdate (http://msdn.microsoft.com/en-us/library/jj155451.aspx)
CCM_SoftwareUpdatesManager (http://msdn.microsoft.com/en-us/library/jj155384.aspx)
Win32_QuickFixEngineering (http://msdn.microsoft.com/en-us/library/windows/desktop/aa394391(v=vs.85).aspx)

We have one additional database in the same database instance as our Orchestrator database for logging. It is called OrchestratorTemp.

For this runbook we use a table called SoftwareUpdate to log the patch status.

softwareupdate

In the reboot runbooks we have another table which logs the general server status which also has columns Servername and RBInstance. With these both columns we later can link both tables and clean up the columns at the end of the process.

I use three runbooks to patch the server.

  1. SCCM Dev – Check updates
  2. SCCM Dev – Install updates
  3. SCCM Dev – Check previous updates

SCCM Dev – Check updates

sccm dev - check updates

It has the following initialize data parameters:

  • Servername
  • Patch (in the reboot runbook you can decide if you want to patch or not, Values: “True/False”)
  • Previous Found (needed for the second run after the reboot, should be “False” at the beginning)
  • RBInstance (reference to the main reboot runbook, can be any number if called outside)

I will focus on the interesting details of the main activies.

  • Get Updates/Check for additional updates (Run .Net Activity):
    Runs the following PowerShell script:
    getupdates
    and publishes the following data:
    getupdates-published
  • Write Updates/Write additional Update Status (Write To Database Activity):
    Writes into the OrchestratorTemp database:
    WriteUpdates
  • Install Update (Invoke Runbook): Initializes the “SCCM Dev – Install Update” runbook and waits for its completion. Loops until Finished=True. Given Parameters: Servername, RBinstance.
  • Check previous updates (Invoke Runbook): Initializes the “SCCM Dev – Check previous updates” runbook and waits for its completion. Given Parameters: Servername, RBinstance.

SCCM Dev – Install updates

sccm dev - install updates

The install updates will be initialized for each update which needs to be installed.

  • Get first missing update (Query Database Activity): Runs the following query:
    get first update
  • Install update (Run .Net Activity):
    Runs the following PowerShell script:
    install update
  • Check update (Run .Net Activity):
    Runs the following PowerShell script:
    check update
    and publishes the following data:
    check update - published
    Loops with a delay of 10 seconds and exits loop when these conditions occur:
    check update - loop
    (pattern: 8|9|10|11|12|13|14|15|16|17|18|19|20|21|22|23)
    => waits 2 minutes for the patch to install. Can be extended by increasing the number of attempts!
  • Cancel Update (Run .Net Activity):
    Runs the following PowerShell script:
    cancel update
  • The Write Update activities sets “ComplianceState” to 1 and the “EvaluationState” to the output status when the update was installed successfully. Otherwise it sets different “ComplianceStates” depending on the update status.

SCCM Dev - Check previous updates

sccm dev - check previous updates

This runbook should check if the update is listed in the installed updates after the reboot.

  • Get Compliance State (Query Database Activity): Runs the following query:
    get compliance state
  • Get ArticleID (Query Database Activity): Runs the following query:
    get articleID
  • Check install status (Run .Net Activity):
    Runs the following PowerShell script:
    Check install status
    and publishes the following data:
    Check install status - published
  • Write Update Compliance (Query Database Activity): Runs the following query:
    Write update compliance

Here is the link to the exported runbooks.

That’s it. Have fun!


30 Sep 12:04

Nightlights

by nobody@smugmug.com (Trey Ratcliff)

Trey Ratcliff
Nightlights

Nightlights

26 Sep 18:15

Functional NES controller coffee table

by Michael Ciuffo

For reddit user [the_masked_cabana], button mashing has taken on a whole new meaning.  His gigantic NES controller coffee table makes it hard to punch in the Konami code without breaking a sweat.

Even before discussing the electricals, this is one impressive build.  Each component was cut from multiple layers of MDF and assembled with screws, glue, and putty.  Once they were sanded smooth, he used layers of carefully applied Krylon paint to achieve a plastic sheen that is remarkably faithful to its 5″ counterpart.  For the more precise lettering, custom cut vinyl stickers did the trick.

Of course, looking the part is only half the battle.  Tearing apart an original NES controller, he soldered wires to the button connections and ran them to eight arcade style buttons located under the replica button covers.  A collection of bolts and springs keep everything aligned and produce the right kind of tactile feedback to the user.  A removable cable in the back provides the connection to the console.

If a four foot NES controller isn’t practical enough for you, he also added some storage space in the base and a removable glass cover that converts the controller into a coffee table.  For more details on the build, check out the reddit discussion.  You can also find an eerily similar working NES controller table in this geeky coffee table roundup from five years ago.


Filed under: nintendo hacks
25 Sep 22:32

The Valleys on the Way to Milford Sound

by Trey Ratcliff

Landscapes and Time

It’s hard for me to picture this before erosion filled in this valley and made it a flat floodplain. I know the geological history and what it theoretically looked like, but it’s so hard to picture things on a geological scale. I think people that can do that must have interesting brains! I used to have a double-major in geophysics, so I’ve always been interested in geology, but just not very good at imagining the time aspect of it…

Daily Photo – The Valleys on the Way to Milford Sound

There are approximately 4,000 places to stop on the drive from Te Anau to Milford, and this is one of them. It’s kind of a must-stop! The scene is crazy-powerful, and it changes throughout the day. I’ve noticed sometimes in the morning it is foggy and hard to see, but it’s still interesting even then. When planning car-trips in New Zealand, it’s best just to add a few extra hours into the experience!

The Valleys on the Way to Milford Sound
25 Sep 21:19

Through the Valleys of New Zealand in a Chopper

by Trey Ratcliff

Sorry, this entry is only available in 中文.

Daily Photo – Over the Top

I’ve taken a few different helicopter rides, but this one below was with Choppy from Over the Top. She’s a super-cool lady and she jams serious music through the speakers while you are flying around. She even landed on top of another mountain and brought out golf balls for us to hit off the edge… fun!

25 Sep 20:49

Systems Center 2012 Orchestrator and PowerShell: Part 1

by The Scripting Guys

Summary: Sean Kearney explains how to use a Windows PowerShell script in System Center 2012 Orchestrator to access variables and published data.

Hey, Scripting Guy! Question Hey, Scripting Guy!

I’m using System Center 2012 Orchestrator at work, but I don’t know how to access the variables and published data in Windows PowerShell. Is it possible? Is it easy?

—SH

Hey, Scripting Guy! Answer Hello SH,

Honorary Scripting Guy, Sean Kearney here. I’m filling in for our good friend, Ed Wilson. He’s busy this week enjoying the beautiful colors in the trees and the foliage.

SH, when you put the word “PowerShell” in your question, the immediate answer is, “Yes, of course! You can achieve almost anything with Windows PowerShell." Right now I’m working on a module to allow Windows PowerShell to tie my shoes! (Of course I’m kidding. I’m pretty certain Ed has already written that.)

So for those of you just stepping in, Microsoft has a tool called System Center 2012 Orchestrator. It’s a really cool piece of technology that allows for some very complex automation to happen—but in a task-based scenario.

The strength of Orchestrator is that it presents a very simple to understand visual automation system. It’s also a very extensible system like Windows PowerShell. In fact, you can have Orchestrator launch Windows PowerShell scripts, which allows you to leverage in-house solutions within an Orchestrator runbook.

Within Windows PowerShell, we have objects like these:

$DOG=”I caught the kitty cat”

$USER=GET-ADUSER –filter “*”

System Center 2012 Orchestrator also has a way to store and retrieve user and system-provided data. But in Orchestrator, we call these Variables and Published Data. For a really great breakdown about System Center 2012 Orchestrator, here is a video from TechEd 2013 to bring you up to speed: Microsoft System Center 2012 Orchestrator: Crash Course.

If you were looking at a Windows PowerShell script in Orchestrator, you would be viewing a window similar to this, which is the .NET task in a runbook:

Image of menu

So as we can see this is a very blank script. It doesn’t have to do much today, other than access data in Orchestrator. So first we do the hard part—create a Windows PowerShell object:

Image of menu

Now if you’ve used Orchestrator before, this is actually the easy part. Right-click the middle of the script, click Subscribe, and select either Published Data or Variable (depending on the particular data in Orchestrator you want to access):

Image of menu

Now you’ll see a representation for the data in Windows PowerShell:

Image of menu

But wait now—you’re not done. You see, this is not a pointer. What Orchestrator will do when you run the Windows PowerShell script within (before it passes to the Windows PowerShell engine), is replace {DomainDNSName} with whatever your value is.

So if the value we had was a string called CONTOSO.LOCAL, this is what would be passed down to our good friend, Windows PowerShell:

$SomeVariableinOrchestrator=CONTOSO.LOCAL

Notice something wrong with this statement? There are no quotation marks around this string. So this would pass down to Windows PowerShell and be run as code, which of course, unless you had an alias called CONTOSO.LOCAL, would simply cough up some nasty error.

So what you’ll need to do is enclose the data in a pair of quotation marks when you subscribe as shown in the following image:

Image of menu

This would now translate to this:

$SomeVariableinOrchestrator=”CONTOSO.LOCAL”

Of course, this will work fine in Windows Powershell.

If the data being published is Date/Time data, you need to precede the Windows PowerShell object with [datetime] to allow it to be properly converted. Otherwise, it will simply be a string. Here is an example of this in action:

Image of menu

There are some situations where you won’t do this. If the data being published or the variable is an integer, there is no need to enclose any of this within quotation marks or precede it with [datetime].

Image of menu

Easy as pie!

Interested? Stick around for this entire week as we discuss Orchestrator and Windows PowerShell, the coolest two-punch combo in the industry—and see how to make them work together!

And tomorrow (if you’re really good), I’ll show you how to publish data to the Orchestrator data bus from Windows PowerShell.

I invite you to follow the Scripting Guys on Twitter and Facebook. If you have any questions, send email to scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Sean Kearney (filling in for our good friend Ed Wilson),
      Honorary Scripting Guy, Windows PowerShell MVP

18 Sep 21:36

36 Reasons To Adopt DataCore Storage Virtualization and Software-defined Storage Architectures

by David Marshall
Welcome to The Virtual Viewpoint: Storage Virtualization - A Contributed Series by DataCore Software Learn the Reasons Why 1000’s of Customers Have... Read more at VMblog.com.