The Use Case
Prestaging content is a fact of life in the SCCM world. Whether you're standing up a new site, cloning a DP, or sending packages to a site with really bad bandwidth, there are a variety of reasons you need to create prestage packages. At multiple contracts I worked, these packages were created by finding the content in the Configuration Manager GUI, right clicking, selecting Create Prestage Content File, and going through the wizard. While this is technically a correct way to do things, it's cumbersome, requires you to remember where everything is in the menu structure, and ties up your console while you do packages one at a time. I could see using this method for one or two packages every now and then, but you're on a PowerShell blog. Here, we're all about scale.
 |
| Not pictured: efficiency |
Making it happen
The Configuration Manager module actually comes with a prestage cmdlet built right in, but this cmdlet is one of the most poorly written ones in all of PowerShell. It has no real intelligence of its own, requiring you to spell out exactly what package type you want to back up. Since every package has a unique PackageID value, I never understood why they didn't just make it use that number and get on with life, but they didn't. Feel free to download the script and follow along.
 |
| I actually couldn't fit them all on one screen |
The Script
The first thing we need to do is declare our variables. This script needs to know what the package ID number is (which can be found literally everywhere the package is mentioned in the SCCM console or WMI interface), what DP we're pulling the content from, and where the file needs to be saved. All of these are mandatory, so you'll be prompted for them if you don't put them inline. Also, depending on the prestage location, you'll need admin rights to move files there, so we just check for those at the outset. We'll also make sure you're connected to your CMSite PSDrive. I also have the script make sure the package isn't already there. Something else to keep in mind is that the DP name needs to be a FQDN when the command runs. If you enter it with just the hostname, the script will sort that out for you, so no worries.
After all the pre-reqs have checked out, the real logic comes in. The first thing it does is try to run get-cmpackge with the package ID, if that comes back as $NULL, meaning there was no package with that ID, it starts down the list of available content types. It checks if it's a software update package, application, boot image, OS image, or driver package. Until it finds something that actually returns an object, it'll keep checking. Then, it makes a mental note of what it found so we can use it later. For troubleshooting and debugging reasons, I like to output the name of the package as well as its source path, but this isn't necessary. It will also tell you where it's going and what it will be named. Then, we use a Switch statement with the count variable (our mental note from earlier) to select the correct Publish-CMPrestageContent flags that actually do the prestaging work for us.
 |
| Figuring out what you wanted |
 |
| Actually prestaging it |
Actually Using It
On its own, it's a nice function to have loaded in my shell. Being able to generate a prestage file without tying up my GUI is always handy, and depending on the organizational skills of the previous SCCM admins, not having to dig around to find a package in their menus can be a real time saver. Where this script comes into its own, however, is when it's chained together with other commands, which is what we'll discuss in our next post.
No comments:
Post a Comment