I previously posted on how to download the Endpoint Protection definitions for installing the EP client during OSD. Greg Ramsey has posted a powershell version of the script to download definitions.
Fellow myITforum member Mark Kent has created a really nice post on using powershell to overcome some issues with software updates installing during a Build and Capture Task Sequence.
Many people who use SCCM to build OS images have come across a slight issue where subsequent “Install Software Updates” task sequences are not finding any patches. This issue occurs because the machine doesn’t refresh it’s update scan and therefore doesn’t think it needs any updates. Brandon Linton detailed some PowerShell commands recently on the MDT-OSD list that can be used to trigger a refresh cycle so additional patches are picked up and applied. Having this issue in our environment, I put this into place and after a little trial and error got them to work as well. I debated using the offline patching method, but we also install Office 2010 into our image and the offline method cannot patch Office.
Trevor Sullivan has created a nice post on checking the size of your Task Sequence’s. This is useful, since there is a 4mb limit to your TS. If you have too many steps, you can run into this issue.
Credit to Greg Ramsey for writing the script.
In addition to this post, be sure to read John Marcum’s blog post:
After upgrading a few servers at a client site, we had to reinstall the Secondary Sites. Surprisingly we didn’t want to resend 400+ packages across the WAN to the remote sites. The PCK files were still sitting on the server from the previous installation.
After reading John’s post and chatting with Greg Ramsey, I decided to use his script. I had a few issues initially and Greg being the awesome guy he is helped me sort them out.
One VERY important thing to note is that you have to send at LEAST one package to the remote site before you can preload content, not sure why that is the case, but John saw the same thing. After sending one package, the preload tool works great.
Once you have the script, you’ll need to make sure the paths are correct for your environment and it’s pointing to the correct server.
Make sure the connection string is pointing to the right server and site code.
Make sure the SMSPKG folder paths are correct.
Make sure the output path is correct as well.
Next we want to run the createpreloadbat.ps1 script in powershell.
You will end up with a preloadpck.bat in the output path and you will see the script spit out all the PCK’s it found.
Next if you run the preloadpck.bat, you will see it update the database. You will see it make the connection to the database and it will let you know if there are any issues. (in this example screenshot the packages are already distributed)
Again, remember you have to send at least one package ahead of time (pick a small one), otherwise you’ll see a rights error.
Finally you can add your DP to the package using the copy packages wizard or CloneDp or whatever you want to use. When the DP receives the request for the package it will use the local PCK instead of requesting a new one.
Download here: PreLoadPkgOnSite
Approving Windows Updates in an MDT 2010 Standalone Environment from a ConfigMgr Software Update Point
Here is a great post over The Deployment Guys Blog. A client actually sent this to me today and I hadn’t read it before. This was one of the main pain points when building your images with MDT Lite Touch.
You’ve no doubt read some of the benefits around using the Software Update Point features of ConfigMgr. However, if you are already using MDT standalone as an Image Engineering environment – there is sometimes a duplication in having to manage software updates in both environments. The most common solution is to set up an external standalone WSUS server for your reference machine to pull down updates. However, it would be ideal to have a single place to manage the approval and download of updates for both the deployed machines in ConfigMgr environment and the reference machine during an image capture in the MDT standalone environment.
Troubleshooting client agent health issues at my current customer, I wanted to eliminate all of the stale systems from AD so I didn’t waste my time on them (and of course the customer was no real help here). I decided to write a script to take a list of systems, check if a forward and a reverse DNS entry exists and also compare the DNS reverse entry (if it exists) to the name of the system as specified in the list. Using these checks, I can now identify systems that probably don’t exist anymore and can be deleted from or disabled in Active Directory thus allowing ConfigMgr to be cleaned up.
Name IP Reverse Status
—- – ——- ——
xyz1 10.1.0.1 abc5 IP registered to another system
xyz2 - - Could not Resolve IP
xyz3 10.1.0.3 xyz3 OK
xyz4 10.1.0.4 - IP Address not found in reverse zone
Actual/exact interpretations of each of the categories is possibly subjective and based on the configuration of a particular environment but in general, IP registered to another system and Could not Resolve IP are indicative of stale systems. Recall that AD System Discovery also does a forward DNS lookup on systems before it creates a DDR on them so this script follows similar logic as the discovery; however, once the system is discovered, AD Discovery won’t remove it and thus this script. Also, AD discovery doesn’t do a reverse lookup because this may or may not be configured in any given environment.
The script is a PowerShell script and can be run on any system that can query the internal DNS. By default, it pulls the names of systems to check from a file called sys.txt in the same directory as the script; place each system name to query on a separate line.
And then, run it from a PowerShell command prompt. To output the results to a CSV, pipe the output of the script to the Export-Csv commandlet; e.g., .\IPCheck.ps1 | Export-Csv c:\IpCheckResults.csv
Nice post by Trevor Sullivan.
Someone recently posted on the MyITforum ConfigMgr mailing list, asking how to delete a bunch of old, empty collections in ConfigMgr. I took this opportunity to write a simple PowerShell script that will do just that. The code simply iterates over all collections, looks to see if each collection has members, and if not, then it prompts the user to delete it.
You’ll need to configure a couple things at the top of the script, before you run it:
ConfigMgr server name ($SccmServer)
ConfigMgr provider namespace (just replace the last 3 characters with your site code)
Add any collection IDs to the $ExcludedCollections array, that you want to explicitly exclude
If you’re really daring, and are absolutely confident that you want to remove all empty collections, you can remove the user confirmation. I’ll leave that up to you, if you’re savvy enough
What is PowerEvents?
PowerEvents is a Windows PowerShell v2.0 module designed to facilitate the ease of creating, updating, and deleting WMI (Windows Management Instrumentation) permanent event registrations. PowerEvents makes it easy to create WMI event filters (define the events you want to capture) and event consumers (responders to events), and then bind them together to initiate the flow of events. By leveraging permanent event registrations, you can perform advanced monitoring functions on a workstation or server, that would otherwise require implementation of an enterprise monitoring product. Because WMI is incredibly vast in the information it provides, very detailed monitoring can be performed using almost any of the WMI objects that exist on a computer.
What are WMI Permanent Event Registrations?
A little-known capability of the WMI service, is its capability to create a permanent registration (listener) for events, and then automatically respond to those events. At a very basic level, it’s "if X happens, do Y" but in this case, it’s all built into WMI, without the need for any additional software.
What Can I Monitor with PowerEvents?
WMI contains a vast amount of information about the Windows operating system, the hardware underneath it, and applications that extend WMI.
Here are a very few examples of events that you can monitor in WMI:
- Microsoft Active Directory
- Changes in group policy configuration on GP clients
- Users created or deleted
- Computer accounts moved
- Microsoft System Center Configuration Manager
- Package created, deleted, or modified
- Advertisement created, deleted, or modified
- Collection created, deleted, or modified
- Monitor Disk Events
- USB flash (UFD) or eSATA drive plugged in or removed
- Detect shrink or expansion of partitions
- Monitor Processes
- Start/stop events
- Change in process priority
- Working set (memory utilization) increase/decrease or exceeds "X" value
- I/O operations increase or exceed a certain value
- Windows Services
- Start / stop events
- New service installed or removed
- Service start type changed
- Device changes
- Detect addition or removal of devices
- Print jobs
- Detect new job or finished job
- Changes in job status
- Software & Patches
- Software installed or removed
- New patches installed
- Operating System
- New reliability records created
- New game registered with Windows 7 Games Explorer
- User Events
- User logon / logoff
- User attributes
- IP address changed
- Default gateway changed
- Network adapter added or removed
- Server Message Block (SMB) session created or ended
- ODBC Data Sources
- Created or removed
- Driver installed
- Configuration changed
- Creation or termination
- Thread state changes
- Microsoft Distributed File System (DFS)
- Last replication time changes
- Errors during replication
- Volume serial # changes
Why Should I use PowerEvents?
Because it’s awesome! In all reality, the capabilities of this module are quite vast, only limited by the information available in WMI. Because many applications extend WMI through WMI providers, these can be not just managed, but also extensively monitored. Additionally, the Windows operating system itself makes extensive use of WMI to provide system information to applications. Through this, you can discover and monitor almost anything you’d want to know about your workstation or server!
- Microsoft Active Directory (AD)
- Distributed FileSystem (DFS)
- Microsoft DNS
- System Center Configuration Manager (SCCM or ConfigMgr)
- Internet Information Services (IIS) 6 / 7
- Windows XP / Vista / 7
- Windows Server 2003 / 2008 / 2008 R2
About the Author
Trevor Sullivan has 7 years of experience in the Information Technology field, and has worked primarily with Microsoft products such as Active Directory, Group Policy, System Center Configuration Manager 2007, Microsoft Deployment Toolkit (MDT) 2010, VBscript, Windows PowerShell, and C#/.NET. Trevor is passionate about sharing with community, and is an active community participant in a variety of mailing lists, forums, blogging, Twitter (@pcgeek86), and other social media outlets.
I had previously posted on a blog where Michael Niehaus created a powershell script to check for the necessary packages for a task sequence.
Jason Schefelmaer has take it one step further and add some prompts to it. See his post and download here.
- ConfigMgr Server Prompt now uses a windows form to keep in form with the other prompts
- Task Sequence prompt has checkbox to allow ‘All Task Sequences’
- Distribution Point prompt also has checkbox to allow ‘All Distribution Points’
- Added new prompt with datagrid showing the missing packages asking to replicate them
- Updated comments, removed unnecessary code I included in the first version.
- Fixed an issue with Distribution Points being assigned to the central server, and not their primary server. (Work around for New-SCCMPackageDP function)