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

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.

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.

Microsoft has released ACT 5.5 (Application Compatibility Toolkit). ACT 5.5 provides support for pre-RTM version of Windows7.

To learn more about ACT 5.5 I recommend reading  “Windows 7 Application Compatibility Toolkit 5.5: Interview with Jeremy Chapman”.

ACT 5.5. can be downloaded here

Another great information source is the Application Compatibility and User Account Control site on Microsoft TechNet.

And finally I came across the blog from Chris Jackson -the App Compat Guy” that is worth a visit as well.

In January 2009 Jeremy Moskovitz launched the Online University for Group Policy Management. I wrote about that earlier in my blog post “Online Group Policy University”.

In the past weeks Jeremy has put an additional great amount of effort in reworking the offerings, so that now you have the possibility of selecting and ordering individual Modules and and options. Additionally there are some very attractive payment options as well that might be interesting for those that don’t get their company paying it for them, but want to invest in their personal knowledge.

There are now 3 different GPO Online University options:

• Build your own
• Silver Package
• Gold Package

The Build your own package allows you to select the individual options that just fit for your needs. So for those that already have bought the GPO books from Jeremy and don’t think they need pre-configured hard drive labs, they can just order the training and documentation material (labs, videos, slides).

Interested ? Then click here and get straight to the GPO Online University starting page or if you don’t want to read the details (because you already did) and can’t wait to place an order, then go here.

Get the latest news around Group Policy Management, subscribe to the GPAnswers Newsletter

Enjoy

When it comes to OS deployment the size of the image to some extend does matter. Windows by default comes with a large set of plug and play device drivers that are included within the operating system installation sources.

Prestaged drivers in Windows Vista and Windows 7 are located under C:\Windows\system32\Driverstore.

If you run the following command against your mounted Windows 7 image file, you get a list of all PnPdrivers included within the Driverstore.

Dism /image:c:\mount /Get-Drivers /all

Now getting back to the image size. Looking at how we could eventually save image size space, I took a closer look at the Windows 7 Driverstore folder size, that on an installed system uses 624 MB. So that looked like a potential candidate to reduce image size.

As mentioned above 624 MB is what the Driverstore uses on an installed system, but how much does it consume within an image, taking into account that there the content is compressed.

Running the following command creates a separate WIM (image) file with just Driverstore content included.

Imagex /capture c:\temp\driverstore\ c:\temp\win7drv.wim “win7driverstore”

The result is that 624 MB Driverstore content now just uses 219 MB. If we add the /compress max option to the above Command brings the size even down to 197 MB. 

Conclusion: Beside the fact that officially the default driver store cannot be modified anyway (if I am wrong here let me know), I think that carrying those +- 220 MB don’t make much of a difference.

Usually when you read a Microsoft Knowledge Base article you find a detailed description on how to solve a particular problem.

In some KB articles you will find the following picture

This indicates that the “Fix it Team” has provided a script / package to automate the system modifications required to fix the problem or change the system behavior.

The fix it team has their own “fix it for me blog” where they list the KB articles they have provided a fix it package.

This is primarily useful for users that aren’t familiar with manually changing the system registry etc, but can also be of use for system administrations.

Yesterday Microsoft released the Release Candidate for Internet Explorer 8 that of course contains a lot of new features that I am not going to rewrite here again, as others did so already.

Reading the IE8 product group blog 100 additional group policy settings are being introduced to extend manageability of IE8 through Group Policy Management. The updated Group Policy Reference including the new IE8 settings can be downloaded here and updated Group Policy Settings ADM files can be found here. Also worth reading is the IE8 Deployment Guide.

And finally for those that want to prevent IE8 being installed in an uncontrolled way throughout their infrastructure can consider using the IE8 blocker toolkit. The IE8 blocker toolkit provides 2 methods to prevent IE8 being automatically installed on your client devices. Method 1 consists of a batch file and Method 2 is a group policy adm template  that allows you to configure IE8 installation blocking through GPO.

.

Today I have been looking into the new “Profiling” options for Windows PE 3.0. Using the profiling options allow you to reduce the content of Windows PE to an absolute minimum without removing any boot critical content.

I am not going to re-write a step by step process here, as it is all described within the Windows PE User Guide for Windows 7 but here are the basic things

1. First build your PE boot.wim the way you have been doing it so far, but before unmounting it run the following command as well: dism /image:C:\PE\mount /Enable-profiling
   
2. Then boot your PE and start doing all the things you will need in the future as well. Just a hint, if you intend to run the ipconfig command, you must run it now, otherwise it won’t be there anymore when you apply the profile.
3. Once you have launched all commands and done whatever you want to do, run the following command: wpeutil saveprofile e:\Optimize_Profile.txt “Image Optimization Profile”
   
   (drive e: is a connected USB stick so that you can copy away the profile file, you will need it later).  
4. Finally rebuild your PE boot.wim, with the command  dism /image:C:\PEHD\mount /Apply-Profiles:c:\optimize_profile.txt and then commit the changes.  Note that you do not need to run dism …../Enable Profiling again here.

The results:

• The first boot.wim was 128 MB in size, a nearly standard boot.wim with some packages added.
• The optimized boot.wim was 62 MB in size.

Happy PE shrinking !

Just found out that Microsoft has released MDT 2010 AND AIK 2.0 BETA on Microsoft Connect. So now we cannot only test Windows 7 BETA but we can also start looking at it’s deployment.

Those of you who are familiar with desktop engineering know the pain of scripting Windows configuration settings. While in general many settings can be configured by adding or changing a specific registry key value, there are still many things within the OS where Microsoft did not make our life as easy and provides a single registry key that can be tweaked.

Yesterday I worked on setting the Windows XP Windows Explorer View to “Details” by default for all users. The typical approach in identifying registry changes is to create a snapshot before and after manally applying the system configuration change, then in most cases the necessary registry keys are found and can be scripted. But unfortunately that wasn’t the case when changing the Windows Explorer View to Details.

It’s a long time ago I had the last request to apply this configuration to build, and back in 2004 I wasn’t able to find a nice solution, so i ended up importing a couple of registry strings that did the thing, but I wasn’t happy about as it was a huge REG_BINARY string that could contain more than just the Details View Setting.

So I made a new attempt in searching for a good solution, others might have found to configure this setting, and I found one that works great on: http://groups.google.com/group/microsoft.public.windowsxp.general/msg/1327cd4eb34fc050

I have embedded the described registry keys within the following REG ADD commands, so that i can be used within an automated scripted client build process.

REG ADD “HKLM\SOFTWARE\Microsoft\Windows\Shell\Bags\AllFolders\Shell” /v WFlags /t REG_DWORD /d 00000000 /f

REG ADD “HKLM\SOFTWARE\Microsoft\Windows\Shell\Bags\AllFolders\Shell” /v Status /t REG_DWORD /d 00000000 /f

REG ADD “HKLM\SOFTWARE\Microsoft\Windows\Shell\Bags\AllFolders\Shell” /v Vid /t REG_SZ /d “{137E7700-3573-11CF-AE69-08002B2E1262}” /f

REG ADD “HKLM\SOFTWARE\Microsoft\Windows\Shell\Bags\AllFolders\Shell” /v Mode /t REG_DWORD /d 00000004 /f

As it looks like, Windows PowerShell will become part of Windows7, so it’s about time to start learning this powerfull scripting language. After i had downloaded PowerShell v1.0 (v2.0 is currently in CTP), i’ve started collecting and searching the documentation and learning guides. I’m not goig to list them all here, most resources and further links can be found on the Microsoft Technet Script Center. But there is one i would like to reference as it is a comprehensive and well written booklet provided and written by a Microsoft Consultant.  Free Windows PowerShell workbook: server administration

Usually when you need a report for a given Group Policy object, you would launch the Group Policy Management Console, select the GPO and then select the settings tab that produces the report.

But what if you need a report for multiple or even all your GPOs you have within your Active Directory ? Going through each GPO and produce the report manually is going to take ages and is boring.

My colleague Rudi recently found a script that automatically creates GPO reports it finds within your AD. You can select them individually or simply report on all.

The script is stored on the Win32 Scripting site which is a usefull resource for admin scripts since many years. The GPO reporting script can be found here

I must have missed this somehow VMWare finally released VMWare Workstation 6.5. For those that didn’t notice it too, here’s the release notes. It does note make sense here to list any of the highlights as there are just too many of them, all described within the release notes. Well…. for those that like automation, have a look at vmrun.

And of course there is also the VMWare Player 2.5.

While searching for something I came across the site computer performance, why the sites is called like that, i don’t know, but it has a lot of interesting content related to windows 2008, vista, scripting etc. so that i find it worth mentioning.

http://www.computerperformance.co.uk/index.htm