How to minimize your ConfigMgr Footprint with 1E

I will be presenting the next 1E webinar – Minimize your ConfigMgr Footprint and Maximize Reliability and Performance.  So if you are currently planning your new ConfigMgr 2012 design or you are looking at ways to trim back your current ConfigMgr 2012 hierarchy, join me on Thursday, May 22nd at 11:00 ET and learn how this can be easily achieved with 1E technology.  Click the above link for registration or head over to http://www.1e.com/events/ for more information and other events.

Originally posted on https://miketerrill.net/

How to minimize the risk of an OSDisaster Part 1

System Center 2012 R2 Configuration Manager does a great job of deploying Windows operating systems.  We (1E) have been able to hit some pretty high success rates in helping our customers with their Windows migrations.  However, if not done correctly, OSD can be very dangerous and can cripple your environment in a short amount of time.  Take Emory University for an example – a simple mistake was made and a Windows deployment was sent out to all laptops, desktops and servers!  With the correct precautions in place, this risk can be easily minimized or even eliminated.

There are several checks and balances that can be put into place in order to prevent something like this from happening and in this post I will focus on Maintenance Windows and limiting Collections.  If you are still stuck in the habit of setting up deployments to All Systems, then the best thing you can do is break that bad habit now!  Otherwise, be sure to keep a copy of your resume updated in case something really bad happens.

The first thing that should be done is to create two root level collections – one for All Workstations and one for All Servers.  Both of these will be limited to the All Systems collection.  Also, you should limit the number of collections that are limited to the All Systems collection for performance reasons, but this goes beyond the intent of this blog post.  If possible, all other collections should be limited to either the All Workstations or All Servers.  By limiting an OS Deployment collection to just the All Workstations, you automatically eliminate the possibility of servers being accidentally targeted (as what happened with Emory University).  Both of these collections only need to be updated once a week and can be enabled for incremental updates.  Each collection will have a query based membership rule that is configured for the System Resource > Operating System Name and Version property.

The last (and most important) thing that needs to be done is an OSD Maintenance Window needs to be configured on each collection.  The key is to make this window in the past.  Please keep in mind that this method is not fool proof, as I will explain below.  Just like wearing a seat belt in a car – it doesn’t prevent you from getting in an accident, but it will minimize the chances of getting hurt.  So, the intention is to minimize the risk, just like we did by splitting up servers and workstations into two different collections.  By creating a window in the past, you will prevent any future OS Deployments from running (provided they were configured with the defaults).  Even if someone accidentally sent the Required OS Deployment to All Workstations, with a maintenance window set in the past, all clients would start returning the following status message:

Message ID: 10074
The program for deployment “AZ1476C5” failed (“AZ105DA7” – “*”). There is no maintenance window with a duration at least as large as the program’s defined maximum runtime. Consequently, the program may never run on the client.

Hopefully, someone monitoring the deployment will see a flood of these status messages and realize that hundreds, if not thousands of systems were about to be re-imaged and correct the targeting collection membership.

When configuring a Required Deployment, the Software Installation and System Restart behavior as it pertains to maintenance windows is unchecked by default.  In other words, someone would have to make a decision to enabled both of these boxes, which would render the above fail-safe solution useless.  In the next part, I will talk about other methods that can be combined with this one in order to further minimize the risk of a OSDisaster.

Below is a PowerShell script that will create the collections, schedules and maintenance windows that I talked about above.  This uses newer cmdlets that are available starting in System Center 2012 R2 Configuration Manager.  As always, test in a lab environment first!

#Create Root Collections with OSD MWs
#Author: Mike Terrill
#Version 1.0

#Disclaimer:
#Your use of these example scripts or cmdlets is at your sole risk. This information is provided “as-is”, without any warranty, whether express or implied, of accuracy,
#completeness, fitness for a particular purpose, title or non-infringement. I shall not be liable for any damages you may sustain by using these examples, whether direct,
#indirect, special, incidental or consequential.

#Set the collection evaluation schedules
$AllWorkstationsSchedule = New-CMSchedule -Start "1/1/2014 12:00 AM" -DayOfWeek Saturday -RecurCount 1
$AllServersSchedule = New-CMSchedule -Start "1/1/2014 12:00 AM" -DayOfWeek Sunday -RecurCount 1

#Create the All Workstations collection
$AllWorkstations = New-CMDeviceCollection -Name "All Workstations" -LimitingCollectionName "All Systems" `
    -RefreshSchedule $AllWorkstationsSchedule -RefreshType Both

#Create the All Servers collection
$AllServers = New-CMDeviceCollection -Name "All Servers" -LimitingCollectionName "All Systems" `
    -RefreshSchedule $AllServersSchedule -RefreshType Both

#Create the All Workstations query membership rule
Add-CMDeviceCollectionQueryMembershipRule -CollectionName "All Workstations" -QueryExpression `
    "select *  from  SMS_R_System where SMS_R_System.OperatingSystemNameandVersion like '%Workstation%'" -RuleName "All Workstations"

#Create the All Servers query membership rule
Add-CMDeviceCollectionQueryMembershipRule -CollectionName "All Servers" -QueryExpression `
    "select *  from  SMS_R_System where SMS_R_System.OperatingSystemNameandVersion like '%Server%'" -RuleName "All Servers"

#Create a 5 min schedule in the past
$MWSchedule = New-CMSchedule -Start "1/1/2014 12:00 AM" -DurationInterval Minutes -DurationCount 5 -Nonrecurring

#Create a restrictive OSD MW that occured in the past
New-CMMaintenanceWindow -CollectionID $AllWorkstations.CollectionID -ApplyToTaskSequenceOnly -Name "Restrict OSD" -Schedule $MWSchedule
New-CMMaintenanceWindow -CollectionID $AllServers.CollectionID -ApplyToTaskSequenceOnly -Name "Restrict OSD" -Schedule $MWSchedule

Originally posted on https://miketerrill.net/

Building the Essential Lab (WIN-B365) Files

Below is a link where you can download the scripts and directory structure that I used in the session No Lab, No Problem! Building the Essential Lab Environment Using Microsoft Technologies (WIN-B365) that I presented at TechEd North America 2014.  For some reason they did not get uploaded to the TechEd Schedule Builder, so I apologize for the inconvenience.  After downloading the zip file, extract it to C:\Lab_Software.  Inside each of the folders there is a read me text file that lists that contents that should be placed in each folder.

WIN-B365 Files

AZ Systems Management User Group presents: Mike Terrill

We are planning on having our third meeting of 2014. This meeting will be held at Microsoft’s Office: 60 East Rio Salado Parkway, Tempe, AZ 85281, 12th floor on Thursday, May 8th. The meeting will start at 3:00 PM with the welcome time at 2:30 PM and will run until 5:00 PM – come early and socialize a bit before the meeting starts.

Come and get an early look at the session Mike will be presenting the following week at TechEd 2014: No Lab, No Problem! Building the Essential Lab Environment Using Microsoft Technologies

The days of requiring extensive hardware and resources to build out a decent test environment are fading fast as new technology and more powerful hardware come out. Yet, often times companies disregard the importance of a lab and take major risks by doing things directly in their production environment. It is always best to have a lab to ‘play’ around in, test that script that is needed to be used in production or simply test and document an upgrade processes. This can easily be done by using equipment and software that is already available and can prevent costly mistakes to a production environment. Using tools like the Microsoft Deployment Toolkit, Hyper-V, PowerShell and a little bit of automation, you can quickly be on your way to setting up the Essential Lab Environment. Once the framework is in place, building out new environments is a snap. Need to refresh a few test client systems or build new ones? No problem! With a reusable solution in place, you should never be without a lab environment again.

Mike is the Systems Management Practice Lead at 1E. He specializes in the design, architecture and installation of Configuration Manager and Windows operating system deployments. Prior to joining 1E in 2007, he worked 10 years for a global strategic outsourcing company as an IT Architect specializing in SMS, software distribution and operating system deployment. His most recent project included deploying System Center 2012 Configuration Manager and Windows 7 to a 450K seat environment. He founded and runs the Arizona Systems Management User Group and has been working with SMS since version 1.2.

Registration Link:
https://clicktoattend.microsoft.com/en-us/Pages/EventDetails.aspx?EventID=187696

Originally posted on http://miketerrill.net

Where to find me at TechEd NA 2014

I am extremely happy to announce that I will be presenting a session at TechEd North America 2014!  The session that I will be presenting is No Lab, No Problem! Building the Essential Lab Environment Using Microsoft Technologies (WIN-B365) on Wednesday, May 14th at 5:00 PM:

The days of requiring extensive hardware and resources to build out a decent test environment are fading fast as new technology and more powerful hardware come out. Yet, often times companies disregard the importance of a lab and take major risks by doing things directly in their production environment. It is always best to have a lab to ‘play’ around in, test that script that is needed to be used in production or simply test and document an upgrade process. This can easily be done by using equipment and software that is already available and can prevent costly mistakes to a production environment. Using tools like the Microsoft Deployment Toolkit, Hyper-V, PowerShell and a little bit of automation, you can quickly be on your way to setting up the Essential Lab Environment. Once the framework is in place, building out new environments is a snap. Need to refresh a few test client systems or build new ones? No problem! With a reusable solution in place, you should never be without a lab environment again.

I am also honored to be a lab assistant for Wally Mead for the following labs:
Deploying Windows 8.1 to Bare Metal Clients on Wednesday, May 14th at 1:30 PM
Upgrading from Configuration Manager 2012 SP1 to Microsoft System Center 2012 R2 Configuration Manager on Thursday, May 15th at 10:15 AM

Additionally, I can be found at the 1E Booth (#1801) throughout the week where I will be demonstrating how to do an OSD Refresh over wireless.