Trevor Sullivan's Tech Room

Minding the gap between administration and development

Posts Tagged ‘windows 7’

Checking Status of a Windows 7 System Image

Posted by Trevor Sullivan on 2011/12/30

If you’re running Windows 7, you may periodically create a “System Image” which is essentially just a VHD backup of your system. When you invoke the task, you will be presented with a dialog box similar to the following, which shows the progress of the backup:


If you are scripting something, and want your script to proceed when the backup has completed, you can run this command line:

wbadmin.exe get status

This program will "block" (continue running) and report progress, as a percentage, until the backup has completed.



Posted in tools | Tagged: , , , , , , , | Leave a Comment »

ConfigMgr: You Receive Error 0x80070490 in a Capture Task Sequence

Posted by Trevor Sullivan on 2011/10/24

If you ever work with Operating System Deployment (OSD) in Microsoft’s System Center Configuration Manager (SCCM / ConfigMgr) 2007, you might build a task sequence that only performs an OS image capture (as opposed to an OS build & capture). You might think — logically — that you only need a single task sequence step to perform this action: a “Capture Operating System Image” step. Unfortunately, this isn’t the case. If you attempt to run a task sequence like this, you’ll probably receive a 0x80070490 error code, which means “element not found.”


Read the rest of this entry »

Posted in configmgr, OSD | Tagged: , , , , , , , , , , , | Leave a Comment »

Restricting Settings by Active Directory Site with Only One GPO

Posted by Trevor Sullivan on 2011/06/30


Have you ever wanted to configure a setting using a single Active Directory (AD) Group Policy Object (GPO), but have a different value for each logical AD “site” in your IT environment? Well, even if you haven’t, there are other folks out there that do. Here is a paraphrased version of an inquiry that I received recently:

“I am working on a Windows 7 deployment, and I would like to have custom wallpapers depending on the physical location. This I am able to do but there are 20+ Active Directory sites and can do it with a GPO assigned to each site. However, it would be easier to manage just a single GPO. Is this possible?”

In short, this person wants 20+ different wallpapers, but doesn’t want to have to create 20+ unique GPOs in order to configure the wallpaper. The most common suggestion in this case, at least historically, would probably be to write a custom user-based logon script (as opposed to a computer startup script) that checks the current AD site, and sets the wallpaper based on that. Granted, that would be a pretty solid solution, however with Group Policy Preferences (GPP), we have another option that requires no knowledge of scripting!

Let’s explore how to use Group Policy Preferences to consolidate multiple desktop wallpaper configurations (per AD site) into a single GPO!

Read the rest of this entry »

Posted in Active Directory, tools | Tagged: , , , , , , , , , , , | 2 Comments »

Silently Installing the Windows 7 AIK

Posted by Trevor Sullivan on 2011/02/08

So I’m working on some automated lab build “stuff” and I tried to silently install the Windows 7 AIK using a simple call to msiexec. Apparently there is something built into the Windows 7 AIK MSI package that prevents it from being installed non-interactively. This is a bit frustrating.

Upon execution of the msiexec command, I received a message in the MSI log, stating: “This MSI can only be installed with full UI.”


I would surmise that, with some MSI hacking, or using a transform, this behavior could be circumvented.

Update (2011-02-09)

Simon and Samuel both posted a solution in the comments. You can use a transform included in the WAIK, like this:

msiexec /i waikx86.msi TRANSFORMS=”waikx86.mst” /qn
msiexec /i waikamd64.msi TRANSFORMS=”waikamd64.mst” /qn

Thanks for the help folks!

Posted in configmgr, OSD, tools | Tagged: , , , , , , , , , , , | 6 Comments »

Removing Permanent WMI Event Registrations

Posted by Trevor Sullivan on 2011/01/18


Since I’ve worked on the PowerEvents PowerShell module, several folks have been confused about how to remove event registrations once they’ve been created. I wrote some documentation that’s included in the download, that explains how to manually remove these registrations using the built-in wbemtest tool. This is the fool-proof method, since wbemtest is included in every Windows installation.

In the interest of making things easier, however, I wrote a WinForms utility in C# a little while back. This utility simply enumerates the various permanent event objects in the WMI repository (filters, consumers, and bindings), and allows you to remove them. That’s all it does 🙂

In the remainder of this blog post, I’ll talk about the manual method of removing event objects, and show you the utility I just mentioned.

The Manual Method

While experimenting with the PowerEvents module, you might accumulate many WMI event filter and consumer objects. At some point, you’ll probably want to clear those out. As of this writing, the PowerEvents module needs further work on the Get-* and Remove-* advanced functions. Until this functionality can be implemented, use the following procedure to remove the filter/consumer bindings.

Here are the individual steps to remove an unwanted event binding:

  1. Open wbemtest as an administrator
  2. Click Connect
  3. In the Namespace field, type root\subscription
  4. Click Connect or press {ENTER}
  5. Click Enum Instances
  6. Type __FilterToConsumerBinding in the text box
  7. Click OK or press {ENTER}
  8. Click the binding instance you want to remove
  9. Click the Delete button

Upon removal of the __FilterToConsumerBinding instance, the consumer will no longer respond to events. This process can be repeated to remove filters and consumers. Rather than enumerating instances of __FilterToConsumerBinding however, you would use “__EventFilter” or any of the five consumer class names.

The WMI Event Helper Utility

The utility I wrote a little while back is intended to display all filters, consumers, and event bindings to you, so that you can remove them from a friendly GUI. Although it works quite well in my personal testing, the tool has one important limitation, albeit it probably won’t affect most people.

The Limitation

In its current form, it does not allow you to specify a WMI namespace where the event objects reside. As I said, most folks should be OK, but you should be aware that you can create WMI filter objects in ANY WMI namespace, not just root\subscription (the default). The out-of-box consumer instances can be created in either root\default or root\subscription (latter is default). Finally, event bindings can be created in ANY WMI namespace.

Unless you’re explicitly specifying an alternate WMI namespace when creating the various WMI event objects, you won’t be affected by this. Just be aware that, if you’re a power user, you might want to make sure you don’t have event objects in other namespaces.

The Tool

Here’s what the tool looks like:


As you can see, it lists filters, consumers, and bindings in the root\subscription namespace. You might notice that above the consumer list, there’s a “Consumer Type” combo box. By clicking the arrow, or scrolling through the list using your mouse scroll wheel (the control must have focus), you can select the Consumer Class that you want to enumerate instances of.

Simply click on the item you want to delete, and select the appropriate “Remove” button. That’s all there is to it!

You can download the WMI Event Helper utility on the PowerEvents project page.


This blog post has covered the removal of WMI permanent event objects both manually, and using a C# event management utility. For more information, please review the comprehensive documentation included in the PowerEvents module release download.

Posted in .NET, powershell, scripting, wmi | Tagged: , , , , , , , , , | Leave a Comment »

PowerShell Module: Enable Wake for Devices

Posted by Trevor Sullivan on 2010/09/23

So in my last post, I shared a PowerShell script that enables you to enable devices to wake up computers. This script relies solely on a WMI interface, but despite the remote nature of WMI, I had provided no method of entering a remote computer name. That changes with the release of my first ever formal PowerShell module! I’ve taken the code from the “enable device wake” script and adapted it to a PowerShell advanced function. I also added the cmdlet binding attribute to it, which makes it an official script cmdlet.

This command more or less replaces the functionality that powercfg.exe -DeviceEnableWake offers.

It has full support for:

  • Script example documentation
  • Named and positional parameters
  • Supports -WhatIf and -Confirm common parameters
  • Configuring remote computers

Download Set-DeviceWake v1.0


Here is an example screenshot of the script’s execution. Please let me know if you have any feedback in the comments or at! As I said before, this is the first PowerShell module that I’ve shared, and I want to make sure it’s done right!

Running on Multiple Computers

(Updated on 2010-09-28)

So, you might be wondering how you can deploy this to multiple computers. The ComputerName parameter only takes a single computer name, rather than an array. You basically have three options here:

  1. Run from management workstation: Wrap the Set-DeviceWake function in a foreach loop, and pipe a text file with a bunch of computer names into the ForEach-Object
  2. Run from management workstation: Wrap the Set-DeviceWake function with Start-Job and a list of computer names
  3. Run on each PC individually: Deploy the script to target workstations via GPO (if they’re Windows 7), or deploy via systems management software, such as ConfigMgr

I don’t have examples handy just yet, but just thought I’d share this information at least!

Posted in .NET, powershell, scripting, tools, wmi | Tagged: , , , , , , , , , , | Leave a Comment »

PowerShell: Finding Currently Loaded DLLs

Posted by Trevor Sullivan on 2010/08/25

I was just browsing through the root\cimv2 WMI namespace this morning, using SAPIEN’s free WMI Explorer tool, when I happened across a WMI class called CIM_ProcessExecutable. In fact, what I was doing in a bit more detail, was going through the CIM_* classes, with the Instances tab selected, so I could discover if any of them were actually usable. I was stepping through them, in reverse order, by hitting {Up Arrow} + {Enter}, and finally came across one that had instances (this one, being CIM_ProcessExecutable).

Now, by clicking through a handful of these instances, it became quickly apparent to me that this class could be useful. It appeared that the classes’ purpose was to correlate running processes (instances of Win32_Process) with files on the filesystem (instances of CIM_DataFile), that are executable. Executable files would typically include files with the .dll or .exe file extensions.

Depending on what you are trying to accomplish, this could be incredibly useful information. For example, a lot of malware can load itself as a DLL in another process, or more simply, as its own executable. This info would be useful in discovering some (but not all) malware. Additionally, since you can get a reference to specific files on the filesystem, you could then determine the version of the file that is loaded into memory. This could be helpful if you are troubleshooting an issue that requires a specific version of an executable file.

Exploring the Class

If we simply enumerate a list of CIM_ProcessExecutable instances, we will get a long list of WMI paths to instances of other classes, specifically Win32_Process and CIM_DataFile. Go ahead and fire up you favorite PowerShell editor, or just the PowerShell console itself, and run this command:

Get-WmiObject -Namespace root\cimv2 -Class CIM_ProcessExecutable

Let’s find out how many executable files are currently loaded on the system. We do that simply by assigning the results of the above command to a PowerShell variable, and then echoing the value of its Count or Length property:

$ProcExes = Get-WmiObject -Namespace root\cimv2 -Class CIM_ProcessExecutable
Write-Host $ProcExes.Count

Retrieving File Properties

Let’s say that we want to just grab a list of interesting file properties, for the loaded executables. In order to do that, we can iterate over the items in $ProcExes, pass the WMI path for the CIM_DataFile instance to the WMI type accelerator in PowerShell, and then select a subset of the properties on the CIM_DataFile instance. Here’s how we do that:

$ProcExes = Get-WmiObject -Namespace root\cimv2 -Class CIM_ProcessExecutable

foreach ($item in $ProcExes)
    # Get the CIM_DataFile instance from the WMI path in Antecedent
    # Pass the CIM_DataFile object to the Select-Object cmdlet, and select only a few properties
    [wmi]"$($item.Antecedent)" | select FileName,Extension,Manufacturer,Version

Here is a sample of the output we’d get from running the above script:

Now we can take that even a step further. Let’s say our goal is to find out these same file properties, but only for non-Microsoft executables. This could help in a malware investigation, even a remote one, since we’re just using WMI here! We can use the Where-Object PowerShell cmdlet to filter the results that are written to the console. FYI, I am using the default short-hand for Where-Object, which is simply a question mark; Don’t let the syntax confuse you 🙂

foreach ($item in $ProcExes)
    # Get the CIM_DataFile instance from the WMI path in Antecedent
    # Filter for only files that are NOT from Microsoft
    # Pass the CIM_DataFile object to the Select-Object cmdlet, and select only a few properties
    [wmi]"$($item.Antecedent)" | ? { $_.Manufacturer -ne 'Microsoft Corporation' } | select FileName,Extension,Manufacturer,Version

As you can see, we’ve added the necessary code to filter out non-Microsoft files. That will work, at least as long as the file’s metadata is properly filled out. As you’ll see from the following screenshot, we still have some files that are obviously Microsoft PowerShell related, but were not caught because the Manufacturer field was missing from the assembly’s metadata.

Viewing Executables for a Process

Since the CIM_ProcessExecutable class binds executable files and processes together (these are not typically a 1:1 relationship), you might want to view all of the executable files that a particular process has loaded. The Dependent property of CIM_ProcessExecutable contains the WMI path to the process that has a particular executable file loaded. Each process has a unique ProcessID, but processes (instances of root\cimv2:Win32_Process) are uniquely identified in WMI by the Handle property. This is verified by examining the Win32_Process.Handle property in WMI Explorer (or wbemtest), and finding that the Key WMI qualifier is set to “True.” The discussion of WMI qualifiers is beyond the scope of this article, but in short, they are metadata that describe WMI properties. You can read more about WMI qualifiers on MSDN.

Typically, we won’t know the handle of a process, but we will likely know at least the name, or maybe even the process ID. Therefore, our process flow, for the goal we just mentioned, would look something like this:

  1. Input a process name
  2. Get the process Handle for the process(es) — we will actually just get the built-in __PATH property, because this directly correlates to the Dependent property on CIM_ProcessExecutable. Then we can avoid doing a LIKE query with just the process handle.
  3. Retrieve instances of CIM_DataFile for the process handle (this would be a string comparison on the Dependent property)
  4. For each instance of CIM_DataFile we retrieve: 1) get an instance of CIM_DataFile using the WMI path in Antecedent, 2) Echo the file properties to the console

Let’s take a look at the code necessary to make the above workflow happen:


function Get-Executables()
    PARAM (
        [string] $ProcessName = $(throw "Please specify a process name.")

        # Retrieve instance of Win32_Process based on the process name passed into the function
        $Procs = Get-WmiObject -Namespace root\cimv2 -Query "select * from Win32_Process where Name = '$ProcessName'"

        # If there are no processes returned from the query, then simply exit the function
        if (-not $Procs)
            Write-Host "No processes were found named $ProcessName"
        # If one process is found, get the value of __PATH, which we will use for our next query
        elseif (@($Procs).Count -eq 1)
            Write-Verbose "One process was found named $ProcessName"
            $ProcPath = @($Procs)[0].__PATH
            Write-Verbose "Proc path is $ProcPath"
        # If there is more than one process, use the process at index 0, for the time being
        elseif ($Procs.Count -gt 1)
            Write-Host "More than one process was found named $ProcessName"
            $ProcPath = @($Procs)[0].__PATH
            Write-Host "Using process with path: $ProcPath"

        # Get the CIM_ProcessExecutable instances for the process we retrieved
        $ProcQuery = "select * from CIM_ProcessExecutable where Dependent = '$ProcPath'".Replace("\","\\")

        Write-Verbose $ProcQuery
        $ProcExes = Get-WmiObject -Namespace root\cimv2 -Query $ProcQuery

        # If there are instances of CIM_ProcessExecutable for the specified process, go ahead and grab the important properties
        if ($ProcExes)
            foreach ($ProcExe in $ProcExes)
                # Use the [wmi] type accelerator to retrieve an instance of CIM_DataFile from the WMI __PATH in the Antecentdent property
                $ExeFile = [wmi]"$($ProcExe.Antecedent)"
                # If the WMI instance we just retrieve "IS A" (think WMI operator) CIM_DataFile, then write properties to console
                if ($ExeFile.__CLASS -eq 'CIM_DataFile')
                    Select-Object -InputObject $ExeFile -Property FileName,Extension,Manufacturer,Version -OutVariable $Executables

    # Do a little clean-up work. Not exactly necessary, but useful for debugging in PowerGUI
        Write-Verbose "End: Cleaning up variables used for function"
        Remove-Item -ErrorAction SilentlyContinue -Path variable:ExeFile,variable:ProcessName,variable:ProcExe,

# Call the function we just defined, with its single parameter
. Get-Executables gmailgrowl.exe

Here is an example of the output we would get, from running the above code. Make sure to change the process name, at the very bottom of the script, where we call the function, to something you’re interested in discovering information about.


That’s all I’ve got for now, folks! Hopefully this gives you some ideas around what else you can do with this information 🙂 There are lots of uncovered gems out there to help you with systems management, and this is just another one of them!

Posted in powershell, scripting, tools, wmi | Tagged: , , , , , , , , , , , , | Leave a Comment »

ccmsetup.exe: Trailing slash in “Source” parameter

Posted by Trevor Sullivan on 2010/08/05

Hello everyone!

Tonight, while I’m traveling in Houston, Texas, I wrestled with ccmsetup.exe for a little while. I was working on getting a ConfigMgr vNext client agent installed on a Windows 7 Ultimate virtual machine, and kept getting a message in my ccmsetup.log saying “Source <path> is inaccessible.


A little bit about %~dp0

Now, whenever I build installer packages for software, whether to run manually, or distribute through ConfigMgr, I generally wrap the commands inside a simple batch file, so I don’t have to constantly type out the entire command, or forget what a particular parameter should be set to.

Because I write lots of simple batch files, and use these packages from both UNC paths, as well as local installs, I use a nifty batch trick: %~dp0. Without going into too much detail, if you use %~dp0 in a batch file, it will reference the folder in which the batch file resides, including a trailing slash. For example, if you want to run a MSI package from a local or UNC path, you could write a dynamic batch file like so:

msiexec /i “%~dp0MyPackage.msi” /quiet

In the above command, the double quotes will take care of any spaces in the path, and the %~dp0 will reference the folder path in which the batch file itself resides. This command also assumes that a Windows Installer package called “MyPackage.msi” resides in the same folder alongside the batch file. Using %~dp0 is great, because no matter where I copy an entire package folder, I always know that I can execute a batch file, and it will use appropriate relative pathing to find the supporting files necessary to run the command.

Anyway, that’s enough history about %~dp0 and why I use it!


The Trailing Slash Issue

Installing the ConfigMgr client is generally quite simple: you can simply execute ccmsetup.exe by double-clicking it, or invoking it, with no parameters from a script. In this circumstance, however, I needed to specify the source folder for where to get the files, otherwise ccmsetup.exe was going to point to my ConfigMgr 2007 management point, rather than the ConfigMgr vNext management point that I wanted it to get the files from. Instead of using the /MP parameter, I elected to simply point ccmsetup.exe to the specific folder where the source files resided (on the ConfigMgr network share).

Naturally, since I was building my agent install batch file right inside the client folder on the site server (\\vnext01\sms_vnx\client), I simply used “%~dp0” to point ccmsetup.exe to its own folder (which was a UNC path). The command I placed into the batch file was the following:

“%~dp0ccmsetup.exe” /retry:1 /source:”%~dp0″ FSP=vnext01.ts.loc

Upon execution of this batch file, is when I experienced the “inaccessible source” error message in ccmsetup.log, as described in my opening paragraph. After encountering this issue, I experimented with a number of different permutations of the command line, none of which worked really. I finally realized that, as best I can tell, ccmsetup.exe appeared to be incorrectly parsing the value passed to the /source parameter. If you include a trailing slash on the <path> you pass to /source, then ccmsetup.exe will actually use the remainder of the command line as the <path>. This is very bad!

In short, if you want ccmsetup.exe to succeed at finding its source files, you must not include a trailing slash on the value you feed into the /source parameter!

The only scenario I have not yet tested, is passing a <path> to /source, that has a trailing slash, but does not have double-quotes around the path. I always recommend using double-quotes for any command-line value that may have spaces in it, so I would not really even consider this scenario, other than for the sake of testing.



Well, I hope this has given some of you some insight into a potential problem, and maybe even saves you a few gray hairs by finding this on Google, instead of stressing over what you are doing wrong. It appears to be a small software bug, and I’m somewhat surprised that no one else seems to have encountered it, but there’s a first time for everything, right?

If you have any feedback, or would like to ask a question, feel free to leave a comment on this article, or e-mail me directly at


Update: If you’d like to help out by recreating the issue, posting your comments, upvoting the bug report on Microsoft Connect, that would be fabulous! Make sure you log into Microsoft Connect, join the ConfigMgr vNext Beta Program, and then click the following link:

If you can reproduce the issue, make sure to click the “I can too” link on the above page.

Posted in configmgr, ConfigMgr vNext, fixes | Tagged: , , , , , , , , , , | Leave a Comment »

Deploying Windows 7 RSAT

Posted by Trevor Sullivan on 2009/11/19

If you’ve got a large number of Windows 7 machines that you’ve already deployed, but now need to silently deploy the Remote Server Administration Tools (RSAT), you’re in luck. It’s quite simple to do, and Microsoft provides the necessary tools to automate this deployment.

The RSAT pack is downloaded as a MSU file, so it is more or less treated like other Windows Updates. Normally, you can just double-click an MSU file to install it, but to automate working with MSU Windows Update files, on Vista and later, we use the wusa.exe utility. Once the RSAT is installed, it must be enabled manually by the end user, in the “Programs and Features” Control Panel applet. To automate working with Windows Features, we use the dism.exe (Deployment Image Servicing and Management Tool) utility.

Download the RSAT 64-bit or 32-bit file, to a folder on your computer. Create a batch file called InstallRsat64.cmdin the same folder, and open it with your favorite text editor, and place the following in its contents:

wusa "%~dp0amd64fre_GRMRSATX_MSU.msu" /quiet /norestart /log:"%WINDIR%\Logs\RSAT Install (64-bit).log"
dism /Online /Enable-Feature /FeatureName:RemoteServerAdministrationTools /FeatureName:RemoteServerAdministrationTools-ServerManager /FeatureName:RemoteServerAdministrationTools-Roles /FeatureName:RemoteServerAdministrationTools-Roles-CertificateServices /FeatureName:RemoteServerAdministrationTools-Roles-CertificateServices-CA /FeatureName:RemoteServerAdministrationTools-Roles-CertificateServices-OnlineResponder /FeatureName:RemoteServerAdministrationTools-Roles-AD /FeatureName:RemoteServerAdministrationTools-Roles-AD-DS /FeatureName:RemoteServerAdministrationTools-Roles-AD-DS-SnapIns /FeatureName:RemoteServerAdministrationTools-Roles-AD-DS-AdministrativeCenter /FeatureName:RemoteServerAdministrationTools-Roles-AD-DS-NIS /FeatureName:RemoteServerAdministrationTools-Roles-AD-LDS /FeatureName:RemoteServerAdministrationTools-Roles-AD-Powershell /FeatureName:RemoteServerAdministrationTools-Roles-DHCP /FeatureName:RemoteServerAdministrationTools-Roles-DNS /FeatureName:RemoteServerAdministrationTools-Roles-FileServices /FeatureName:RemoteServerAdministrationTools-Roles-FileServices-Dfs /FeatureName:RemoteServerAdministrationTools-Roles-FileServices-Fsrm /FeatureName:RemoteServerAdministrationTools-Roles-FileServices-StorageMgmt /FeatureName:RemoteServerAdministrationTools-Roles-HyperV /FeatureName:RemoteServerAdministrationTools-Roles-RDS /FeatureName:RemoteServerAdministrationTools-Features /FeatureName:RemoteServerAdministrationTools-Features-BitLocker /FeatureName:RemoteServerAdministrationTools-Features-Clustering /FeatureName:RemoteServerAdministrationTools-Features-GP /FeatureName:RemoteServerAdministrationTools-Features-LoadBalancing /FeatureName:RemoteServerAdministrationTools-Features-SmtpServer /FeatureName:RemoteServerAdministrationTools-Features-StorageExplorer /FeatureName:RemoteServerAdministrationTools-Features-StorageManager /FeatureName:RemoteServerAdministrationTools-Features-Wsrm

This should install all of the available RSAT components for 64-bit Windows. The code below should install the 32-bit version (just call the batch file InstallRsat32.cmd).

wusa "%~dp0x86fre_GRMRSAT_MSU.msu" /quiet /norestart /log:"%WINDIR%\Logs\RSAT Install (32-bit).log"
dism /Online /Enable-Feature /FeatureName:RemoteServerAdministrationTools /FeatureName:RemoteServerAdministrationTools-ServerManager /FeatureName:RemoteServerAdministrationTools-Roles /FeatureName:RemoteServerAdministrationTools-Roles-CertificateServices /FeatureName:RemoteServerAdministrationTools-Roles-CertificateServices-CA /FeatureName:RemoteServerAdministrationTools-Roles-CertificateServices-OnlineResponder /FeatureName:RemoteServerAdministrationTools-Roles-AD /FeatureName:RemoteServerAdministrationTools-Roles-AD-DS /FeatureName:RemoteServerAdministrationTools-Roles-AD-DS-SnapIns /FeatureName:RemoteServerAdministrationTools-Roles-AD-DS-AdministrativeCenter /FeatureName:RemoteServerAdministrationTools-Roles-AD-DS-NIS /FeatureName:RemoteServerAdministrationTools-Roles-AD-LDS /FeatureName:RemoteServerAdministrationTools-Roles-AD-Powershell /FeatureName:RemoteServerAdministrationTools-Roles-DHCP /FeatureName:RemoteServerAdministrationTools-Roles-DNS /FeatureName:RemoteServerAdministrationTools-Roles-FileServices /FeatureName:RemoteServerAdministrationTools-Roles-FileServices-Dfs /FeatureName:RemoteServerAdministrationTools-Roles-FileServices-Fsrm /FeatureName:RemoteServerAdministrationTools-Roles-FileServices-StorageMgmt /FeatureName:RemoteServerAdministrationTools-Roles-HyperV /FeatureName:RemoteServerAdministrationTools-Roles-RDS /FeatureName:RemoteServerAdministrationTools-Features /FeatureName:RemoteServerAdministrationTools-Features-BitLocker /FeatureName:RemoteServerAdministrationTools-Features-Clustering /FeatureName:RemoteServerAdministrationTools-Features-GP /FeatureName:RemoteServerAdministrationTools-Features-LoadBalancing /FeatureName:RemoteServerAdministrationTools-Features-SmtpServer /FeatureName:RemoteServerAdministrationTools-Features-StorageExplorer /FeatureName:RemoteServerAdministrationTools-Features-StorageManager /FeatureName:RemoteServerAdministrationTools-Features-Wsrm

I do realize that the line extends way off to the right, but just copy the whole thing, and you will get the entire command-line. If you have any issues with dism.exe, check out the log file located in %WINDIR%\Logs\Dism\dism.log.

Please leave any questions in the comments section below! Thanks for reading!

Posted in tools | Tagged: , , , , , , , , , , , | 11 Comments »

Windows 7 – WaitFor.exe

Posted by Trevor Sullivan on 2009/11/19

So I just randomly came across this utility built into Windows 7 that simply sends or waits for a signal (message). This could be useful for batch scripts that need to wait for something to happen on a local (or remote) machine.

Here is the help output from the command:

C:\Users\Administrator>waitfor /?

WaitFor has two ways of working:
Syntax 1: to send a signal     WAITFOR [/S system [/U user [/P [password]]]] /SI signal Syntax 2: to wait for a signal     WAITFOR [/T timeout] signal Description:     This tool sends, or waits for, a signal on a system. When /S is not     specified, the signal will be broadcasted to all the systems in a     domain. If /S is specified, then the signal will be sent only     to the specified system. Parameter List:     /S     system         Specifies remote system to send signal to.     /U     [domain\]user  Specifies the user context under which                           the command should execute.
    /P     [password]     Specifies the password for the given user context.     /SI                   Sends the signal across the net to waiting machines     /T     timeout        Number of seconds to wait for signal. Valid range                           is 1 - 99999. Default is to wait forever for signal.     signal                The name of the signal to wait for or to send.     /?                    Displays this help message.     NOTE: A system can wait for multiple unique signal names.     The signal name cannot exceed 225 characters and cannot     contain characters other than a-z, A-Z, 0-9 and ASCII     characters in the range 128-255. Examples:     WAITFOR /?     WAITFOR SetupReady     WAITFOR CopyDone /T 100     WAITFOR /SI SetupReady     WAITFOR /S system  /U user /P password /SI CopyDone

Let’s look at an example of how to use it. All we have to do is set up a listener, and then use another command prompt to send the signal to it. For the sake of example, we’ll use the message “blah“.

1. Set up the listener

Listening for a signal

Listening for a signal

2. Send the signal (from a different command prompt)

Send the signal

3. Observe the listener result

See listener results

 And that’s all there is to it! A simple, but handy utility if you’re writing batch scripts! It even sends a signal to a remote system, using the /S switch! You could also use this utility with the Microsoft Deployment Toolkit (MDT) 2010, to help control the flow of your task sequence.

Posted in scripting, tools | Tagged: , , , , , , , | 2 Comments »