ConfigMgr 2012 OSD Notes

Written by Fred Bainbridge.

Attached is the slide deck and the refreshMP script that I referenced during the OSD presentation at the October MNSCUG meeting.  This script should be copied the device early in the task sequence and then run after every reboot via run command line and a static path to the vbs file.  This will help avoid problems where the device can't contact the MP/DP after a reboot.  Be aware, an application/package installation that returns a 3010 will reboot the task sequence unless you define it not to in the package/application itself.  Know were your reboots are happening so you can run this script after each reboot.  

Rumor has it if the configuration manager client has the CU2 update installed this reboot issue is a non issue.  Give it a shot and let me know.

Take aways from the presentation - 

  • Know your application exit codes
  • Be prepared to break down the app model if it has reboots
  • Application Model works fine with OSD.
  • Configure appropriate task sequence variables for your environment.
  • Make sure your problems are not external to ConfigMgr.  Networking issues perhaps?
  • Get statistical significance with your builds.  1 successful build is useless.  10 in a row is a good start.

Here are good references for building your OSD Task Sequence -

I can be reached @FredBainbridge.  Thanks!

OSD Presentation Slidedeck

RefreshDefaultMP Script

August 2014 MNSCUG Meeting - Notes

Written by Fred Bainbridge.

The August meeting was a great success!  Both presentation were fantastic.  A big thank you to Jonathan Almquist and Nathan Foreman!  Concurrency provided stellar food and drink as well.  Great times were had by all.  

Here are the details and examples of Nathan's presentation on integration SCOM with a CMDB.

As a reminder, elections for MNSCUG board members is going to be held at the October meeting.  Must be present to run or vote.  Get involved, it's well worth it.  

Also, MMS is coming up!  Have you registered yet?  You should!



September 2014 MNSCUG Meeting - Notes

Written by Fred Bainbridge.

Last night was all sorts of awesome.  Thanks to Ryan Andorfer!  He showed some really amazing SMA uses.  Jaw dropping stuff.  

Also - we never got the name of the guy who won the epic rock paper scissors duel. Oops!  Please contact me to claim your prize!  

Below are notes from the meeting.  However if you missed it these notes do not do it justice.  It was absolutely astounding, eye watering, make you rethink your life type of stuff...

SMA notes -

  • PowerShell has a larger user base than Orchestration.  This appears to be a fair statement based on a user poll of attendees.
  • Orchestration was not designed to be a PowerShell engine, but it was something it could do.
  • Opalis was purchased by MS and the first release looked just like Opalis. Orchestration 2012 R2 felt the same way and was more like a hot fix.  However included in the release was SMA. 
  • SMA is a PowerShell based automation engine.  The biggest difference between SMA and Orchestator is that SMA does not have a drag and drop interface (yet). 
  • Drag and Drop looks good to management but downplays actual real world complexity.  This is not reality.  There is a reason really smart people have either not automated or have automated something (PowerShell).  Drag and Drop is not a good representation of business processes.
  • SMA is web service oriented and has runbook servers along with a database.  (similar to Orchestrator). There is no more thick client, SMA is all web based client.
  • The SMA web based UI is housed in windows Azure pack.
  • Why SMA - standard language PowerShell 4.0 (not old 32 bit PowerShell). Scalable infrastructure.

SMA lessons learned -

  • Nothing is extraordinarily simple.  Its not PowerShell, its PowerShell Workflow!  This is a significant difference.  Aka, learn PowerShell workflow!  It is essential for automation work.
  • Use checkpoints to be able to know what happens when a service or server dies during a process. 
  • Inline scripting - takes a block of code and runs it normal PowerShell.  You can change this block of code to run as a different user. 
  • Author your tools locally.  Use the ISE.  i.e.  Test the workflow from outside of SMA.  USE SOURCE CONTROL!!  I.e. Team Foundation Server.
  • Follow the normal Development process when working with SMA / PowerShell.  DEV-> QA -> Prod.
  • Orchestration made it VERY hard to promote or demote code from tier to tier. (QA to prod, etc)
  • Workflow vs. Module - repeatable code use a module.  For business specific tasks use a workflow. 
  • SMA Monitors - this is a concept from Orchestrator.  I.e. how do you tell an automation to do work?    Push and Pull methods.  (looking for information or getting handed information)
  • Track your executions - you do this to keep metrics on how much time you have saved.  This is critical to justifying an automation team.
  • SMA can load balance across runbook servers.

Getting started with SMA - (First learn PowerShell)


July 2014 MNSCUG Meeting Notes

Written by Brian Mason.

Thanks to our VP Fred Bainbridge who took these excellent notes about the last meeting. Thanks to Concurrency for the great food!

Ryan Ephgrave - Right Click Tools

Using the right click tools you can right click on a user and go to user devices and it will show you how many devices the user has been on and for how long.