Managing ActiveX Components within an enterprise sometimes can be a pain. Users with standard user privileges by default can’t install ActiveX components, hence whenever a larger group of users require an ActiveX component you usually end up creating a software package and distribute it via Software Distribution or you provide them with temporary Administrative rights. But if the clients are running Windows Vista or Windows 7 there is another solution available I noticed many people aren’t aware of, hence that’s why I am writing this article.

The Solution is the Windows ActiveX Installer Service. Using the Windows ActiveX Installer Service allows Enterprise Administrators to manage the deployment of ActiveX controls through Group Policy Settings. On Windows Vista the ActiveX Installer Service is not installed by default but can be added as a feature. On Windows 7 the Service is installed by default.

Configuring the ActiveX Installer Service through Group Policy can be done in two ways. Either by specifying the ActiveX Control installation URL or by configuring trusted sites. I am going to use the first option to demonstrate the configuration and behavior of the ActiveX Installer Service.

Most of you will be familiar with the Microsoft Connect, MSDN Subscriber Download or TechNet subscriber download Site that uses the File Transfer Manager for downloading content. When trying to download content from one of the above mentioned web sites for the first time with a standard user you will be prompted with a message as shown in the picture below.

But as soon as you allow the Add-on to be installed, you will be prompted to provide a user name and password of a user that has administrative privileges to allow the installation to continue. 

This is what would happen in an enterprise environment where users access a website that requires the installation of an ActiveX control. So let’s create a Group Policy that allows the installation of the Microsoft File Transfer Manager through the ActiveX Installer Service.

First we need to know the URL that points to the ActiveX Control installation file, which is usually a CAB file but can be an OCX or DLL file as well. To find out the URL of the Microsoft File Transfer Manager I open the web site’s source and search for the word “CODEBASE”.

Now that I know the location that points to the CAB file, I open the Group Policy Management Console and create a new GPO called GPO_ActiveX_Management. Within the new created GPO I navigate to the ActiveX Installer Service which is located under Computer Configuration, Policies, Administrative Templates, Windows Components.

I then enable the "Approved Installation Sites for ActiveX Controls” setting and add the Site name https://transfers.ds.microsoft.com/FTM/TransferSource/grTransferCtrl.cab and set the Installation control value to 2,1,1,0.

To ensure that the GPO settings is applied to my client I run GPUPDATE at the command prompt. Now when i launch the website again that tries to install the Microsoft File Transfer Manager there is no User Account Control prompt anymore, this because i have now configured this site as an approved site to install an ActiveX control.

When opening the Services list within the Microsoft Management Console, I can see that the Service has been started and looking at the Windows Application log I can see that the URL was identified as a secure location.

So after a few seconds, the Microsoft File Transfer Manager is successfully installed without having to provide administrative privileges.

If you’re interested in using the ActiveX Installer Service in your environment I recommend that you also read the below referenced articles.

Additional Resources
The ActiveX Installer Service in Windows Vista
Microsoft TechNet – ActiveX Installer Service
NirSoft – ActiveXHelper

When installing Applications or operating system hotfixes the installation process sometimes requires replacing or deleting files that are in use, if that is the case these files can only be replaced or deleted during the next system reboot.

When you plan to install multiple applications in a row you can run into the situation where an application cannot be installed due to a pending FileRename operation from a previous application installation. So if you plan to install several applications in a row without a reboot, it’s highly recommended to check if a given application does actually require a reboot or not. If you launch the installation process manually you will most likely get a “Reboot required” prompt at the end of the installation. But if you run your installation packages in silent mode with the REBOOT=ReallySuppress option you will not notice if a reboot is required or not.

The information for Pending FileRename Operations is stored within the Windows Registry under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ under the key PendingFileRenameOperations if this key does not exist there are no Pending FileRename Operations, if the key does exist the key value data contains the files that need to be replaced or deleted.

Mark Russinovich provides two useful utilities that deal with Pending FileRename Operations PendMoves.exe and MoveFile.exe. PendMoves.exe allows you to list any pending filemoves and FileMove.exe allows you to configure the system to replace or delete a file during the next system reboot. The tools can be downloaded from here and for more information you might also want to read this article. For those that are looking for a script based solution have a look at the WMI script from Tom Mills which does the same as PendMoves.exe.

Other interesting resources describing Pending FileRename Operations are:
Microsoft TechNet: A Restart from a Previous Installation is Pending
Description of the new features in the package installer for Windows software updates

Microsoft Security Essentials (MSE) is Microsoft’s free Antivirus Software which helps protecting clients against viruses and spyware. For years I had used other free Antivirus programs on my home based clients, but have switched them all to MSE since it’s release in September 2009.

The MSE binaries are located in the following folder: C:\Program Files\Microsoft Security Essentials. In that folder we also find the MpCmdRun.exe which provides a command line interface for MSE. The tool provides the following options:

-? / –h
Displays all available options for this tool

-Trace [-Grouping #] [-Level #]
Starts diagnostic tracing

-RemoveDefinitions [-All]
Restores the installed signature definitions to a previous backup copy or to the original default set of signatures

-RestoreDefaults
Resets the registry values for Microsoft Antimalware settings to known good defaults

-SignatureUpdate [-UNC]
Checks for new definition updates

-Scan [-ScanType]
Scans for malicious software

-Restore -Name <name> [-All]
Restore the most recently or all quarantined item(s) based on name

-GetFiles
Collects support information

When I booted my Windows 7 client this afternoon, the virus and spyware definition status was set as shown in the picture below.

After running mpcmdrun –SignatureUpdate the definition files were updated.

When using the –scan option you can define whether you want to run a default, quick or full system scan. To run a quick scan simply type MpCmdRun –scan –1 at the command prompt.

By running MpCmdRun –Getfiles a file called MPSupportFiles.cab is being generated and stored under C:\ProgramData\Microsoft\Microsoft Antimalware\Support. The cab file contains all relevant data related to MSE. (log files, registry settings and events)

Additional Information
Microsoft Security Essentials Home
MSE – Microsoft Security
How to manually download the latest definition updates for Microsoft Security Essentials

Just found this post on Trevor Sullivan’s Tech Room blog which explains how to automate the Windows 7 Remote Server Administration Tools (RSAT) installation. Read the entire article here

As we move towards the end of the year I thought it’s a good time to do some housekeeping activities within the lab infrastructure in which we work on a daily basis. Throughout the year we often create test user and computer objects within Active Directory and of course sometimes we forget to delete them.

As I don’t want to reinvent a wheel again I searched the web and soon found a whole bunch of tools and scripts that would help me identifying unused user accounts. I decided that I wanted to use a script. I first found the Last Logon Dates scripts from Richard L. Mueller which are written in WSH. But then I found the Managing AD User Accounts with PowerShell article on WindowsITPro and decided to use the opportunity of using PowerShell to accomplish my task.

Unfortunately the administration console I use hasn’t been migrated to Windows 7 yet, so I installed PowerShell 2.0 onto that Windows Vista client and then installed the Quest AD cmdlets.

On PowerShell.com I found the following script that I modified a bit so that the output is written into an HTML file.

Get-QADUser -sizeLimit 0 | where {$_.lastlogontimestamp -lt (get-date).AddDays(-30)} | Select NAme,description,lastlogontimestamp | convertto-HTML | Out-File c:\temp\adlastloggedon.htm

I wanted to do the same to find old computers, but it appears that the Get-QADComputer cmdlet has a bug, as it doesn’t return any LastLogonTimestamp values and I found various comments that this was identified as a bug which should have been fixed by now, but either the bug is still there or I might be doing something wrong. However I found a “find old computer objects” script on the Microsoft TechNet Script Center Gallery it just has a bid more lines of code

Note that your Windows domain must be at Windows 2003 Domain Functional Level for updates to the llastLogontimeStamp to occur.

If you are looking for a command-line tool to find Old Computers in your domain, I recommend the OldCmp tool from Joe.

Related content:
The LastLogonTimeStamp Attribute” – “What it was designed for and how it works

The Application Paths Editor allows you to add, edit and remove Application Paths. Setting an application path for your favorite application or script allows you to run the application directly from the “Run” dialog at the Start Menu.

So assume you have a script called “HelloApp.vbs” which is stored under C:\Program Files\HelloApp without having set an Application Path, you would have to navigate to the scripts folder or type the full path to launch the script. But once you have set an Application Path, you can launch it directly form the run dialog at the Start Menu.

Application Paths are stored in the Windows Registry, so if you are familiar with editing the Registry, you can of course also add Application Paths directly there.

  The Application Paths Editor can be downloaded from here

Adobe Flash and Shockwave are probably one of those most installed applications on home and enterprise computers. Working within the End User Computing environment for large enterprise customers since quite a while, I can’t remember of just one company that wouldn’t maintain Adobe Flash and Shockwave in their list of enterprise standard applications.

But when it comes to distributing these applications, many companies seem to go down the difficult route instead of taking the easy one. When distributing applications within Enterprise environments, you want them to install automatically, hence you need a software package.

Many companies seem to create their Adobe Flash and Shockwave installation packages by capturing the installation sources that are used when initiating an end user installation from the Adobe website as shown in the picture below.

The challenge of this method is that you need to capture the sources while the web based installer is running (these are stored temporarily on the system) and that you probably want to get rid of any additional software that is being installed such as the Google Toolbar in this case.

Many people seem not to be aware that Adobe does provide redistributable media for enterprise deployment of their Adobe Flash and Adobe Shockwave players. On the download pages of the appropriate Player, you will see a link called “Distribute Flash Player” or “Distribute Shockwave Player”

By clicking on one of these links you are being redirected to the Adobe Player Licensing website where you find the links to apply for a license and obtain the installation media to distribute the players within your enterprise.

License Flash Player ›
License Shockwave Player ›

You will have to provide some information like Company name, number of seats and the operating system used. Once you have submitted your request, it takes about 5-10 minutes until you will receive an e-mail with the links to download the players.

Well, that is what I consider as taking the easy route, clicking on a link, filling in a form, and after let’s say 15 minutes you get the install_flash_player_10_plugin.msi for Flash and sw_lic_full_installer.msi for Shockwave and you’re ready to go.

A similar method is available for Adobe Reader. I plan to post an article about that soon.

Windows Virtual PC requires that your hardware supports hardware-assisted virtualization. There are a number of third party utilities around already, but now Microsoft released one as well. It’s called the Hardware-Assisted Virtualization Detection Tool and can be downloaded from here

If you launch the tool manually it will tell you if your system meets the requirements for running Windows Virtual PC or not, quite similar as the Securable utility I wrote about in the Detect XP Mode Support article.

But since I usually work in enterprise environments, I’m more interested in command line automation than in visual user interfaces, so let’s see what we have here.

When downloading the tool you get the havdetectiontool.exe, which is a self extracting executable. So the next step is to extract the content which we do by running the havdetectiontool.exe /x command which will prompt you for a location where to store the content. Once extracted you will see a havtoollauncher.exe and a subdirectory called Sources that contains the havtool executables for both 32 and 64 bit clients.

I was not able to find any command line options for the havtoollauncher.exe itself, so i moved on the to the 32 bit version of the havtool.exe. And yes, indeed the tool does provide command line options, Hura!

Executing the following command will parse the output into a log file:

havtool /log havresult.txt /q

Content of havresult.txt

System CPU doesn’t support Hardware Assisted Virtualization.
BIOS Vendor : Hewlett-Packard
BIOS Version : F.22    
System Manufacturer : Hewlett-Packard
Final returnValue = 1

Executing the following commands will set the result into the Errorlevel variable and then create a new System Variable called HAV and sets its value with the Return code.

havtool /q
SETX /M HAV %ERRORLEVEL%

Setting a system variable is just one example, you could also write a custom registry key or log file. Once you have marked your system with the result, you can use your system management software such as SCCM 2007 to collect the data and create your custom reporting.

If you consider using XP Mode, then I recommend watching this video. This video contains a good tutorial on how to install and configure XP mode including a lot of additional hints. Furthermore the video explains how to create a customized XP Mode VHD for deployment on multiple clients.

The video can be downloaded from here

An old colleague called me up this week (well in fact it was my old boss who has left our company), and told me about an issue they had when deploying an ISP specific Software Package that interacts with the Wireless Devices on their HP notebooks.

The problem was that if the WWAN device has been turned of via the quick launch button by the end user, the software would not install.

What many don’t know is that there is a command line  utility that allows you to automate the Wireless Device State on HP devices. If you have the HP Wireless Assistant Software installed, you should have the utility wireless.exe stored under C:\Program Files\Hewlett-Packard\HP Wireless Assistant.

Launching wireless.exe without providing any command line options will show a dialog box describing all available command line parameters.

So if you want to enable all Wireless Devices automatically on a HP notebook system, then simply run the following command:

C:\Program Files\Hewlett-Packard\HP Wireless Assistant\Wireless.exe all on

Or if you just want to turn on the Wireless Lan Device, use the following command:

C:\Program Files\Hewlett-Packard\HP Wireless Assistant\Wireless.exe WirelessLAN on

You can see the state of the individual Wireless Devices within the HP Wireless Assistant Application.

Instead of opening several windows, here’s an easy way to get a list of installed QFE’s. simply open a command prompt and type:

WMIC QFE

or

WMIC QFE get caption,hotfixid,installedon

or if you are looking for a specific update, enter the following command:

WMIC QFE | find “958559”

where 958559 relates to the MS KB number. If the QFE is installed, it will be listed.

Related posts:

3 seconds to get system serial number

During my weekly “let’s see what’s new”  search on some of my favorite websites, I found the “Bitlocker Deployment Sample Resources” on the MSDN Code Gallery. The Resource Page contains a lot of documentation and useful script samples for the deployment and management of Microsoft Bitlocker.

Being one of the lucky ones who was able to sign-up to the Microsoft Office 2010 Technical Preview program, I have started looking at the deployment of Microsoft Office 2010 today.

My first observation was that unfortunately the provided documentation seems to be ahead of the Office Installation sources that have been made available for download. I noticed this when making an attempt to run the setup.exe /admin command which would normally launch the Office Customization Wizard, but it wouldn’t because the necessary components that are usually located within the Admin folder aren’t available yet, in fact the whole Admin folder as such seems to be missing. OK, so no advanced customizations for now, back to basic.

The current Office 2010 beta that is made available for download is packaged into an executable called “O2010_SingleImage_retail_ship_x86_en-us.exe”. (32 bit version). To create the administrative installation point, extract the content using the following command:

O2010_SingleImage_retail_ship_x86_en-us.exe /extract:c:\office2010

You should then see the following content within the C:\Office2010 folder.

As a next step, open the config.xml file located within the folder SingleImage.WW and modify the file as shown below. (replace the product key with the one you received).

And finally create a batch file that runs the following command:

setup.exe /config SingleImage.WW\config.xml

Office 2010 Beta will now be installed in silent mode. this might be helpful when planning an automated deployment for testing purposes.

More about Office 2010:

Microsoft Office 2010 Engineering blog

Backstage with Office 2010

Office 2010 – The Movie (I recommend watching this one)

Office 2010 for IT Pros

A Look At Office 2010 with Chris Capossela

Some of you might have noticed that after installing the .NET Framework 3.5 Service Pack 1, there can be a leftover folder in the root of the system as shown in the picture below.

We identified this issue right after .NET 3.5 SP1 was installed,  and found out soon that we were not the only ones having this issue. Microsoft describes this behavior in KB951847 and confirms the folder can be deleted.

After you install the .NET Framework 3.5 SP1 in Windows XP or Windows Server 2003, there is an arbitrary folder that is generated in the root of drive C. This folder contains two subfolders that are named amd64 and i386. These two subfolders both include the following files:

Filterpipelineprintproc.dll
Msxpsdrv.cat
Msxpsdrv.inf
Msxpsinc.gpd
Msxpsinc.ppd
Mxdwdrv.dll
Xpssvcs.dll

These files were pending to be deleted from the XPSEPSC installation.

But deleting that folder doesn’t appear to be so easy. When trying to delete the folder, you get the following error message:

When taking a closer look, you will notice that the folder as special permissions set, so the only way to get rid of this folder is to first take ownership of the content and then delete the folder. When working in an enterprise environment where we are used to automate things, manual steps are not an option, things must run in an automated way.

So we created a script. Since the folder names used by the windows update process are created randomly, we first need to identify the folder name. This is done by simply searching for the file mxdwdrv.dll that is not located in the Windows folder. Once we have identified the random folder name we need to take ownership of the folder before deleting it. We use the SubInACL resource kit utility from Microsoft to take ownership of the folder. Finally we can delete the folder.

Note that the below script will only work if the system was rebooted after the .NET Framework 3.5 SP1 installation.

dotnet35leftoverfix.vbs

‘ dotnet35leftoverfix.vbs
‘ version 1.0
‘ 03.08.2009
‘ ——————————–

‘ The script expects SubInACL.exe to be present within the same folder as the script itself.

Dim WshShell : SET WshShell = CreateObject(“WScript.Shell”)
Dim oFSO : SET oFSO = CreateObject(“Scripting.FileSystemObject”)

‘Find where mxdwdrv.dll is located other than c:\windows
Dim colFSOSubFolders
‘On Error Resume Next
Set oFolder = oFSO.GetFolder(“C:\”)
Set colFSOSubfolders = oFolder.Subfolders
For Each objSubfolder in colFSOSubfolders
‘if its found it in WINDOWS then ignore it

if ucase(objSubfolder.Name) <> “WINDOWS” then
    if oFSO.FileExists(“C:\” & objSubfolder.Name & “\i386\mxdwdrv.dll”) then
        ‘ok this subfolder name is what I need to go after
        cmdline = fcurdir & “subinacl /subdirectories ” & objSubfolder & “\*.* /setowner=Administrator /grant=Administrator=F”
        msgbox cmdline
        wshshell.run cmdline , ,true
        oFSO.DeleteFolder(objSubfolder)
    end if
end if
Next

function fCurDir()
set o=CreateObject(“Scripting.FileSystemObject”)
set of=o.GetFile(WScript.ScriptFullName)
fCurDir=of.ParentFolder&”\”
set of=Nothing
set o=Nothing
end function

This script is provided “as is”.  The author offers no warranty or guarantee of any kind. Use of this script is at your own risk. The author takes no responsibility for loss of data.

UPDATE 27. October 2009

If you are working in an enterprise environment and want to get rid of the folder in an automated way on many systems, the above script might be of use for you. If you are a HOME user and have no scripting skills, I recommend you use one of the manual based solutions below. Thanks to all those that have contributed to this article.

Windows7 comes with Windows Installer 5.0 that has a new installation property called MSIFASTINSTALL. Using the MSIFASTINSTALL property can help reduce time required to install a windows installer package.

The trick behind MSIFASTINSTALL is quite simple, it just skips things that consume time like creating a system restore point or calculating the space requirements (File Costing). So if you do not need system restore points and know that your clients have enough disk space anyway, you could consider using the MSIFASTINSTALL property to speed up application installations.

The table below shows the results of the tests I have performed on Windows7 Enterprise build 7201 with 2 rather small packages.

I used the following commands:

msiexec /I Firefox-3.5-en-US.msi MSIFASTINSTALL=1 /l*v C:\MSTTEST\Install.log /qb

msiexec /I skypesetup.msi MSIFASTINSTALL=1 /l*v C:\MSTTEST\Install.log /qb

Note that I had enabled logging to track the installation duration. 

More information about the MSIFASTINSTALL property can be found here. You might also want to take a look at the FASTOEM property.