This is basically two posts in one, add logging to your scripts in the script node, and Get Service Windows Info, check if you have any deployments being squashed by too restrictive Services Windows, and remove the service windows if you want to. Why add logging… several reasons, to know what the script did, to have a “paper trail”, and helps with troubleshooting. I’ve added logging to my scripts for accountability as well. I have it log to a network share because I’m not local admin on the boxes I’m running the scripts on, so having a central share to collect the scripts is very important to me when I’m troubleshooting issues.
The reason I wrote this script was because we've run into machines that would never run the Upgrade because they would return with a status message "deployment will never run, too restrictive of service window". We do not check the box on our deployments to run outside of a Service Window, as we want to respect what the Business Unit have said are their approved times to service machines. However there are times when the windows are just too small for the time we've specified in our TS, or someone created a local service window manually, using a tool like Client Center, to accomplish a one-off task and never cleaned it up. So I created a script that would read the execmgr.log file, search for a restrictive window issue, then delete them (based on parameters). You can search for Local Service Windows or Server Side (Collection) Service Window and delete those, or choose Delete all service windows. Common Sense Warning: Use with Caution, and Test please. This script is deleting Service Windows which restrict installs / reboots from happening all willy nilly. If you start removing those restrictions… well.. you get it.
Super quick post, basically I had to do this today and I don’t want to forget when I replace my source file server next time.
What: Setting up Alias name for CM Source File Server, so when the server is replaced, you move the Alias name to the new server, so it never impacts your Package Content Source Path.
How: NetDom – TechNet Blog HERE
Right about now you might be saying “Ok Gary, this is great, but I didn’t plan ahead, should I wait to when I replace the server to set this up, or just do it now?” I say, “DO IT NOW!”.. All future content you can use the Alias name, and as you get time, you can prune old garbage and update rest of the package properties to the alias path.
To make that process a bit easier,
@NickolajA created this nifty tool to migrate your paths via automation. TechNet Gallery
Posted on GARYTOWN.COM
UPDATE: 8/20 - Adam Gross (@AdamGrossTX) added more info and explain even more! That guys is awesome, really nice walk through on how to do it with a script to automate! Check it out HERE
UPDATE: 8/17 - Heard back from MS. Rest of those Dynamic Updates need to be applied offline to your Build Media, they are NOT included in the monthly CU. (Read full article for context)
Dynamic updates, what are those things? Well, as Microsoft says “With Dynamic Update, if you start a computer from an existing operating system (for example, Windows 8), and then run Setup from that operating system [IN PLACE UPGRADE], Setup [Windows 10 Upgrade Setup] can check for new Setup files, including drivers and other files.” You can enable it in your TS on the Upgrade OS step: (yes, you want to do this if you have bandwidth, way more info HERE, Thanks Adam)
WARNING... WORK IN PROGRESS... This has been in my drafts for a couple months, I'm pretty busy so I don't know when I'll get to polish it, so for now, just publishing it with intent to go back and update it. Since I wrote this, there has been several changes already, due to advances in CM, finding bugs, etc. Anyway, because this is really never going to be 100% done, just going to click publish now, so you can start playing with it...
PS.. Mike Terrill is working on a very detailed blog post that will hopefully answer many of your questions as well, but he is waiting for making his more polished, he takes more pride in his blog posts than I do. 🙂
Download the Task Sequences and Content ---> HERE <--- I will try to keep that updated as I update my Lab's TS
Ok, so about a couple weeks ago, I posted the Pre-Cache Compat Scan Task Sequence, in Part 1, now it’s time to go over the IPU. It’s taken a couple weeks as I keep updating, refining, and finally came to the realization, I could keep tweaking this forever and never get around to posting. So, I figured, I should just post this, even if it’s not 100% complete. Just this should be pretty helpful to many.
Super short post, just more for self-documenting.
I found tons of scripts out there to do this, but they all required having to reset ccmexec before the cache size updates. So… if you do it from the control panel, you don’t have to reset the service… what were those scripts doing wrong, that the control panel was doing right? Mike Terrill told me… the Control Panel uses the COM object, so lets just do that with Powershell!
Super Simple (1 Line!)
Sure you can break it out into more lines if you’re going to make a script to make it more “read-able”, but I like 1 liners.
(New-Object -ComObject UIResource.UIResourceMgr).GetCacheInfo().Totalsize = "25000"
In Task Sequence Run Command Line Step:
powershell.exe -command "(New-Object -ComObject UIResource.UIResourceMgr).GetCacheInfo().Totalsize = ""25000"""
Originally Posted on GARYTOWN.COM