General Microsoft

What has changed from PowerShell 1.0 to PowerShell 2.0?

Windows PowerShell is an extensible automation engine from Microsoft, consisting of a command-line shell and associated scripting language. Windows PowerShell is built on top of, and is integrated with, the Microsoft .NET Framework.

powershellAdditionally PowerShell enabled easy access to COM and WMI to provide an environment in which administrators perform administrative tasks on both local and remote Windows systems.

Windows PowerShell 2.0 installs under the System32/WindowsPowerShell/V1.0 folder. PowerShell 2.0 is backward-compatible with PowerShell 1.0. However, the following points should be noted: 

Breaking changes from PowerShell 1.0

  • The value of the PowerShellVersion registry entry in HKLM\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine is changed to 2.0.
  • New cmdlets and variables have been added. These additions might conflict with variables and functions in profiles and scripts.
  • The -IEQ operator performs a case-insensitive comparison on characters.
  • The Get-Command cmdlet gets functions by default, in addition to getting cmdlets.
  •  Native commands that generate a user interface cannot be piped to the Out-Host cmdlet.
  • The new Begin, Process, End, and Dynamic Param language keywords might conflict with similar words used in scripts and functions. Interpreting these words as language keywords might result in parsing errors.
  • Cmdlet name resolution has changed. In Windows PowerShell 1.0, a runtime error was generated when two Windows PowerShell snap-ins exported cmdlets with the same name. In Windows PowerShell 2.0, the last cmdlet that is added to the session runs when you type the command name. To run a command that does not run by default, qualify the cmdlet name with the name of the snap-in or module in which it originated.
  • A function name followed by ‘-?’ gets the help topic for the function, if one is included in the function.
  • Parameter resolution for Microsoft .NET Framework methods have changed. In Windows PowerShell 1.0, if you called an overloaded .NET method that has more than one best-fit syntax, no error was reported. In Windows PowerShell 2.0, an ambiguity error is reported. In addition, in Windows PowerShell 2.0, the algorithm for choosing the best-fit method has been revised significantly to minimize the number of ambiguities.
  • If you are enumerating a collection in the pipeline and you try to modify the collection in the pipeline, Windows PowerShell throws an exception.

For example, the following commands would work in Windows PowerShell 1.0 but would fail after first pipeline iteration in Windows PowerShell 2.0:
$h = @{Name=”Hello”; Value=”Test”}
$h.keys | foreach-object {$h.remove($_)}

To avoid this error, create a sub-expression for the enumerator by using the $() characters. For example:
$($h.keys) | foreach-object {$h.remove($_)}

Restricted verbs and characters:

If you use the Import-Module  cmdlet to load commands that use unapproved verbs or restricted characters in the command name, you will receive a warning. Use the Get-Verb command to see a list of the approved verbs. Do not use any of the following characters in command names: [ # , ( ) { } [ ] & – / \ $ ^ ; : ” ‘ < > | ? @ ` * ~ % + =

Reserved keywords and parameter names:

Windows PowerShell 2.0 has reserved certain keywords as part of language syntax and some names that can be used as parameters to commands, as follows: 

  • Reserved language keywords: USING, CLASS, DEFINE, and VAR
  • Reserved parameter names: –SelectProperty and –SelectObject

Windows Presentation Foundation (WPF) hardware acceleration:

The graphical elements of Windows PowerShell Integrated Scripting Environment (ISE) might not render correctly if you are using Windows Presentation Foundation (WPF) hardware acceleration. If the graphical elements do not render correctly, disable the WPF hardware acceleration, especially if you are using older video drivers or virtualization software. For more information, see

Help over remoting might not work:

If a user is calling the get-help Windows PowerShell command over Windows PowerShell remoting from a highly/partially (not fully) localized operating system, the help content will not be displayed. Users will see only the command syntax, but no help content for the command and its parameter. To work around this issue, users should copy a localized help file (whichever one they want to make the default) from the localized folder under c:\windows\system32\WindowsPowerShell\v1.0\<locale> to the application/module base folder. (The default path for Windows PowerShell commands is c:\windows\system32\WindowsPowerShell\v1.0.)

Courtesy: Windows Management Framework Relese Notes – Here

Microsoft Windows Installer, Application Compatibility and Deployments

Download – Windows Management Framework Release Candidate

The Microsoft Windows Management Framework Release Candidate (RC) build for Windows Vista, Windows Server 2008, Windows XP, and Windows Server 2003 includes the following components:

WinRM 2.0

Windows Remote Management (WinRM) is the Microsoft implementation of WS-Management Protocol, a standard Simple Object Access Protocol (SOAP)-based, firewall-friendly protocol that allows hardware and operating systems from different vendors to interoperate. The WS-Management protocol specification provides a common way for systems to access and exchange management information across an IT infrastructure.

PowerShell 2.0

Microsoft Windows PowerShell is a new command-line shell and scripting language designed for system administration and automation. Built on the .NET Framework, Windows PowerShell enables IT professionals and developers to control and automate the administration of Windows and applications.

BITS 4.0

Background Intelligent Transfer Service (BITS) is a service that transfers files between a client and a server. BITS provides a simple way to reliably and politely transfer files over HTTP or HTTPS. Both downloads and uploads are supported. Unlike other protocols that transfer files in the foreground, BITS transfers files in the background (by default). Background transfers use only idle network bandwidth in an effort to preserve the user’s interactive experience with other network applications, such as Internet Explorer. Foregound (or normal) transfers are also supported

This RC release is available in English, German and Japanese. The final release will be available in a broader set of languages.

Please note that this build is an RC release and should not be deployed on self-host systems as there may be issues with installation/uninstallation and general usability.


Microsoft Windows Management Framework is designed for systems that wish to use the new Windows Management features on downlevel platforms. The system must have the following software installed: Windows Vista SP1, Windows Vista SP2, Windows Server 2008, Windows Server 2008 RTM, Windows XP SP3, or Windows Server 2003 SP2

Installation Instructions

The following are the installation instructions for the Windows Management Framework RC release. These steps may change for the final release.
Step 1: Please select the file that matches the architecture on your computer, the version of Windows on your computer, and the components you wish to install:

  • Architecture: x86 or x64
  • Windows Version: Windows Vista, Windows Server 2008, Windows XP, or Windows Server 2003
  • Components: Core (WinRM 2.0 and PowerShell 2.0) or BITS 4.0

Step 2: Copy the appropriate file from the website to your local desktop.
Step 3: Double click the file and launch the installer.
The installation will prompt for a reboot.

Download the framework here ! ! !

General Microsoft

Attention FireFox Users !!!

Remember that Microsoft .NET Framework Assistant add-on that Microsoft sneaked into Firefox without explicit permission from end users?

Well, the code in that add-on has a serious code execution vulnerability that exposes Firefox users to the “browse and you’re owned” attacks that are typically used in drive-by malware downloads.  The flaw was addressed in the MS09-054 bulletin that covered “critical” holes in Microsoft’s Internet Explorer but, as Redmond’s Security Research & Defense team explains, the drive-by download risk extends beyond Microsoft’s browser.

A browse-and-get-owned attack vector exists. All that is needed is for a user to be lured to a malicious website. Triggering this vulnerability involves the use of a malicious XBAP (XAML Browser Application). Please not that while this attack vector matches one of the attack vectors for MS09-061, the underlying vulnerability is different.  Here, the affected process is the Windows Presentation Foundation (WPF) hosting process, PresentationHost.exe.

While the vulnerability is in an IE component, there is an attack vector for Firefox users as well. The reason is that .NET Framework 3.5 SP1 installs a “Windows Presentation Foundation” plug-in in Firefox.

Now, Microsoft’s security folks are actually recommending that Firefox users uninstall the buggy add-on:

For Firefox users with .NET Framework 3.5 installed, you may use “Tools”-> “Add-ons” -> “Plugins”, select “Windows Presentation Foundation”, and click “Disable”.

This introduction of vulnerabilities in a competing browser is a colossal embarrassment for Microsoft.  At the time of the surreptitious installs, there were prescient warnings from many in the community about the security implications of introducing new code into browsers without the knowledge — and consent — of end users.

Courtesy: Thanks to Zdnet for this information post !!

Also, If you havent run the patches yet., please do that immediately.

How-to Microsoft Windows Installer, Application Compatibility and Deployments

Troubleshoot the error 1603 “Fatal Error During Installation”

This error message is displayed by the Microsoft Windows Installer Engine (Wondering whats this? Read here) and is a general error code that indicates a problem occurred during the installation. Read on this article to learn how to sidestep this speed bump. The following is the probable list of known causes for this error to occur:

  • Short file name creation is disabled on the target machine.
  • An Install Script custom action is prototyped incorrectly.
  • A file is locked and cannot be overwritten.
  • The Microsoft Windows Installer Service is not installed correctly.
  • The Windows Temp folders are full.
  • The setup was corrupted after installation and, therefore, fails with this error during un-installation.
  • An older version of Install Shield Developer is being used.
  • Print and File sharing is not installed if your application needs it.

Troubleshooting 1603 MSI Error

As discussed, The 1603 error code is mostly returned when any action fails during an installation on Windows, and most commonly it indicates that one of the custom actions in the MSI failed. When we encounter a failed setup with return code 1603, here are the steps that we should follow:

Re-run the setup with verbose logging enabled using steps similar to those that are listed here.

Step 1: Generate a verbose log file named msi*.log in the %temp% directory the next time the setup package is executed. (Click here to know more ways to generate log). Know more about the command-line switches here.

msiexec /i <msipath>setup.msi /l*v c:\temp\msi.log

Step 2: Open the verbose log in a text editor such as notepad and search for the string “return value 3”. In nearly all cases, this will take us to the section in the verbose log that lists the action that failed that initially caused setup to rollback.

Step 3: Review the contents of the log file immediately above the “return value 3” string to determine which custom action or standard action failed. Depending on which action is failing, We will need to proceed to more detailed debugging from here.

One can find that the biggest hurdle to debugging a failed setup is often zeroing in on which part of the setup is actually failing, and this trick of searching for “return value 3” ends up helping speed this process up in nearly all cases. Of course, it does not work in 100% of scenarios.

You can find some ways of troubleshooting the logs here –

“Access your favorite Windows Applications from your Android/iOS device with a virtual desktop by of the best Desktop as a Service providers. Get a free trial of Office 365 and excellent support by

Known Solutions

The following solutions have resolved this error in the majority of cases:

  1. Make sure short file name creation is enabled on the target machine. You can check to ensure that the target machine does not have short file name creation disabled by navigating to the following registry entry:

    Make sure the value “NtfsDisable8dot3NameCreation” is equal to 0. This indicates that short file name creation is enabled. A value of 1 indicates that this functionality is disabled. You should change the value to 0. After modifying this value, the target machine should be rebooted before attempting to launch the setup again.

    Note: If the target machine should normally have short file name creation disabled, it can be disabled after the install completes by resetting “NtfsDisable8dot3NameCreation” to 1 and rebooting.
  2. To ensure that the Windows Installer Service is properly installed and configured, it is recommended that users install the file InstmsiA.exe on Windows 95/98/Me or InstmsiW.exe on Win NT systems. These files are shipped with your InstallShield product and are located in the following location: <Product Path>\Redist\Language Independent\i386. If the service is installed, to know the status of the service exection, you could also goto services.msc in the command prompt, check the status of the Windows Installer Service. “Stopping and restarting it can help”
  3. Empty all temporary folders. The specific temporary folders for a machine can be determined by accessing the DOS prompt and typing set. Note the values listed for TEMP and TMP, and delete all files in those locations.
  4. Make sure no other applications, including utilities such as virus scanners, are running in the background. Close all running applications and utilities, and launch the installation again.
  5. If this error occurs during un-installation, use the Microsoft Windows Installer CleanUp utility to uninstall the installation. Once the installation has been successfully un-installed, you can then debug the project to determine what caused the original error.

If it doesn’t fall in this last, it could be any other error which occurred during the installation, do update in the comments..lets fix that..!

LinkedIn and other Discussions

I had also posted this on LinkedIn Discussions and have got some quality responses for the same – I will extract some information from there and post it here so that, you can get all the information at one single place.

A Senior Desktop Analyst, Jack Fei writes,

Vijay has makes some excellent points about how to troubleshoot these types of issues. From my experience, the fix is usually trivial once you understand “how to correlate verbose logging results” with msi internals.

First, know that “installation” means msiexec.exe sequentially processing rows of the InstallExecuteSequence table inside the msi database.

Second, know that msiexec.exe processes the commands sequenced between InstallInitialize and InstallFinalizes in two passes. A way to think about it is the first pass “conditionally installs the change” to the machine while checking the syntax of the command and the second pass “commits the change to the machine”. A 1603 essentially means “an error occurred” trying to commit the change, causing msiexec.exe to “backout the change”.

This type of error is either caused by msi misengineering (most vendor msi are misengineered) or by an “machine specfic issue”. So Patrick Pepin makes an excellent suggetion to check the msi vendor.

Having VMWare or imaging tool really helps troubleshoot this type of issue.

1. I would determine the issue can be reproduced on a clean machine with all pre-requisites installed (just to eliminate the possibility false negative caused by testing on an unknown or corrupt pc environment).

2. If it is a capture msi (original source is non-msi) I would systematically exclude files and registry keys until I isolated the component causing the issue in my msi. I built it, so I know best how to fix it.

3. if the msi was engineered by another vendor, I would review the verbose log and isolate the failing instruction in the InstallExecuteSequenceTable. My major technique was to find the failure that generated the “1603” error and find the likely instruction that caused it. To test my theory, I would comment out only that instruction (put a negative sign in the sequence column) and rerun the command. Sometimes, I would get lucky and even “work around” the msi defect by leaving the custom action commented out. This type of change works great when the custom action is doing “unnecessary checks” for desktops in your environments. Obviously, I would “test the modified msi” and make sure the application installed and starts cleanly.

4. If I can reproduce the problem on a clean desktop, I will have good ammunition to contact the vendor. However, my experience is if you know how to do what I have outlined, you will exhaust the technical support departments of whatever vendor you call. This is done for “political reasons” more than anything else – so you can be the hero when the vendor despite considerable persistance from you, can not find a solution.

Good luck. Hope this helps.

Best Practices Microsoft Windows Installer, Application Compatibility and Deployments

Importance of a RunOnce Key in Device Driver Installation

Well, The Run and RunOnce registry entries help programs to be run automatically. In device driver installations,  A RunOnce entry is executed immediately after the driver is installed; These entries are not executed until the user logs on.

For a Client-side installation, all RunOnce entries are executed. No Run, RunEx, or RunOnceEx entries are executed.
For a Server-side installation, Setup looks for RunOnce entries in the INF in the format described on the DDK. The DLLs specified are run in the system context with no UI. Any RunOnce entries that do not follow this format are deferred to a client-side installation and are run in administrator context with UI.

This is the primary reason for special requirements on RunOnce entries.

Addition Information: Run, RunEx, or RunOnceEx entries are executed only in the context of a logged-on user, and are not executed immediately after device is installed. A Service entry can immediately provide functionality for multiple logged-on users, whereas Run entries provide service to them only when the user next logs on, and also run one instance for each user.

For more information on RunOnce and Run Keys, Check these links –

General Microsoft

Remote Desktop Connection 7.0 (RDC7) client for Windows XP and Windows Vista

Today, The Windows Team announced the upcoming release of the Remote Desktop Connection 7.0 (RDC7) client for Windows XP and Windows Vista. RDC7 will allow users who connect to machines running Windows 7 and Windows Server 2008 R2 from Windows XP or Windows Vista to take advantage of features such as Windows Media Player redirection and true multi-monitor support.  For more information on RDC7, see this blog post on the Remote Desktop Services Team Blog.

The release candidate for the Windows Management Framework is also available. This is a collection of tools to help IT Professionals manage a mixed environment of Windows 7, Windows Vista, and Windows XP PCs and includes:

  • Windows PowerShell 2.0
  • Windows Remote Management 2.0
  • Background Intelligent Transfer Service (BITS 4.0)

For specific details or to download the release candidate, click here.

The Windows Team believes that, these tools will be extremely useful to IT Professionals transitioning their organizations and applications to Windows 7. We can expect to have the final versions of the RDC7 client, the Windows Management Framework, and the Platform Update available sometime in Q4 2009.

Best Practices Microsoft Windows Installer, Application Compatibility and Deployments

List of all Windows OS Version Numbers

Version Check is a basic operation which every developer does while building applications. Microsoft says, wrong Conditions may cause Application Compatibility issues to both developers and users, when they look at migrating the existing applications to a newer OS. The Windows version is actually composed of a bunch of different fields, all packed into an OSVERSIONINFO structure.

The relevant parts of the OSVERSIONINFO are:

  • Major Version (dwMajorVersion)
  • Minor Version (dwMinorVersion)
  • Build # (dwBuildNumber)

List of Windows Client OS with their Version Numbers

Operating System Version Number
Windows 1.0 1.04
Windows 2.0 2.11
Windows 3.0 3
Windows NT 3.1 3.10.528
Windows for Workgroups 3.11 3.11
Windows NT Workstation 3.5 3.5.807
Windows NT Workstation 3.51 3.51.1057
Windows 95 4.0.950
Windows NT Workstation 4.0 4.0.1381
Windows 98 4.1.1998
Windows 98 Second Edition 4.1.2222
Windows Me 4.90.3000
Windows 2000 Professional 5.0.2195
Windows XP 5.1.2600
Windows Vista 6.0.6000
Windows 7 6.1.7600
Windows 8.1 6.3.9600
Windows 10 10.0.10240

Yochay Kiriaty says that “A lot can go wrong when version checking is misused. A user might experience a “silent fail” where the application simply fails to load and nothing happens. Or, a user might see a dialog box indicating something to the effect of “you must be running Microsoft Windows XP or later” when in fact, the computer is running Windows 7. Many other consequences to poor version checking can inconvenience users as well.”

Reference- Windows Team Blog

Using appropriate conditions to determine the OS is a very important step to ensure App-Compatibility. For more information on Application Compatibility Operating System Versioning and Windows 7 RTM – Read Here and Here.
Microsoft Windows Installer, Application Compatibility and Deployments

How to hide a program in Add Remove Programs?

Setting ARPSYSTEMCOMPONENT property to 1 does make the application program to be hidden in the Add/remove programs.

The ARPSYSTEMCOMPONENT property in Windows Installer does not actually do anything directly to your installation. The Add/Remove Programs (ARP) applet always queries the Windows Installer for application and patch information to display on the Control Panel Window. When ARPSYSTEMCOMPONENT is not defined for a package, all the data is read from the registry key under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall.

When the property is set to 1, these entries are not written in the registry and hence, do not appear in the Control Panel Add/remove applet.

Also, setting ARPNOREMOVE property to 1 will just disable the remove button from Add/remove Programs.

Check the link below for more information on other MSI Properties

Windows Installer, Application Compatibility and Deployments

How to Implement DLL Isolation in Wise Package Studio?

“DLL Isolation” is used when our application needs to have a specific version of a shared DLL for its functionality. This just copies the DLL into the same folder as the EXE that needs it.

Steps to Follow (Wise Package Studio):
1. On the Components tab in Setup Editor, right-click the .DLL you want to isolate.
2. From the right-click menu, select New > Isolated Component. The Isolated Component Details dialog appears where you pick a file for isolation from the feature that contains the component.
a. If the key path for the current component is not an .EXE, then the drop-down list shows all .EXEs in the containing feature that are key paths of .DLL files.
b. If the key path for the current component is an .EXE, then the drop-down list shows all files from the containing feature that are key paths other than the current component.
3. From the Associated File drop-down list, select the .EXE you want to assign to this .DLL.
4. Click OK.

The limitation is that we can only have one version of the DLL loaded in memory at a time. I.e., App A loads DLL version 1 and then App B tries to load DLL version 2 but can’t. App B ends up hanging or blowing up.

Reference: WPS for Newbies

Best Practices How-to Microsoft

Darwin Descriptors in Windows Registry – Cryptic Strings

The most common method of ensuring applications remain highly available is through Windows Installer file associations. This mechanism operates very much the same way as Windows Installer shortcuts, but instead of directly linking to an application’s executable file, the association is made by a registered file type.

As you can see in Figure below, Windows Installer file associations are defined using the same mechanism that standard file associations use, with one exception. Notice that an extra value is listed under the typical “shell\Open\command” registry key. The extra value (also named “command”) is where Windows Installer looks any time you double-click on a file from within the Windows shell. This cryptic-looking string, sometimes referred to as a “Darwin Descriptor” is actually an encoded representation of a specific product, component, and feature. If this extra value exists, Windows Installer will decode the data, and use it to perform checks against that product and component. If the component is found to be missing or corrupt, Windows Installer will launch a repair to restore the missing file or data, and finally launch the referenced application as normal, passing the appropriate command-line options to it.

Cryptic-looking string - Darwin Descriptors

Viewing a “Darwin Descriptor” for a file association

Cryptic-looking string - Darwin Descriptors

Viewing a “Darwin Descriptor” for a COM Server

The Darwin Descriptor for COM Advertising is stored as the InProcServer32 registry value. The advertised shortcut’s TargetPath is a combination of the ProductCode & Darwin Descriptor + some tags. Open the shortcut using ex. notepad and find the descriptor. A Darwin Descriptor is an encoded string and when decoded produces a combination of the ProductCode, Feature & ComponentId(s).As the Darwin Descriptor is stored as a “REG_MULTI_SZ” entry it can contain more then one descriptor where other packages may have installed same component. We can find Darwin Descriptors under the following locations

HKCR\Installer\Assemblies and HKCR\Installer\Components

Cryptic-looking string - Darwin Descriptors


Cryptic-looking string - Darwin Descriptors


Cryptic-looking string - Darwin Descriptors

While Packaging, we can use snapshot with advertising (not registry as-is) as it gives some extra entrypoints (Darwin Descriptors) to trigger a potential repair if required. If there are some problems for the application to call any COM component/ActiveX functions then Advertsing setting “Retain Registry Information as-is” works better.

Thanks to AngelD, who shared this information!