VMMap v2.6: VMMap, a powerful process virtual and physical memory analysis tool, now shows both graphical and numeric breakdowns of private virtual memory, as well as heap configuration flags.

Disk2vhd v1.5: Disk2Vhd v1.5 works with Hyper-V SCSI direct-attached volumes and reports an error when a snapshot includes offline volumes.

LiveKd v3.14: This version of LiveKd has better detection of the Debugging Tools package installation and launches the debugger in a mode that skips the unnecessary root-cause analysis of the virtual dump file.

Sigcheck v1.66: This update to Sigcheck, a file version and signature checking utility, fixes a bug in the certificate revocation check logic.

Mark’s Blog: Case of the Slow Logon: Mark’s latest blog post documents a troubleshooting case that highlights the use of PsExec to monitor the logoff or logon process and the technique of Process Monitor log comparison to pinpoint a problem that caused some machines in a corporate network to experience 3-minute logons.

 Process Explorer in PC World’s Top 75 Windows Tips of All Time: We’re proud that Process Explorer was cited as one of PC World Magazine’s top Windows tips.

Desktops v1.02: v1.02 works around another issue that could prevent Alt+Tab from working on alternate desktops on 64-bit Windows 7 systems.

Sigcheck v1.65: Now includes all certificate errors in the unsigned image filter, not just images that have no code signing certificate.

DiskView v2.3: Includes a native 64-bit version that allows it to handle multi-terabyte disks when run on 64-bit Windows.

Thank you so very, very much.

The “Restricted” execution policy isn’t intended to be something that PowerShell users live with forever. It’s a safe default that protects non PowerShell users from being impacted by PowerShell-based malware.

For example, many home users had never used VBScript, but still got bitten by the flurry of WSH-based viruses that got mailed to them. PowerShell’s Restricted execution policy solves this. To an attacker, a computer that has never used PowerShell is the same as a computer that doesn’t have PowerShell installed at all. And since attackers look to affect the largest number of computers possible, PowerShell becomes a less attractive vehicle for their attack. That, in turn, makes PowerShell users safer too. Given all of PowerShell’s security barbs, an attacker is better off using executables or other popular scripting languages as an attack vehicle.

So in light of all this, the Exchange team updates the execution policy to RemoteSigned by our recommendation. If you are an application that uses PowerShell support, you probably fit into one of these situations:

You expect the vast majority of your users to run your scripts

If you are a vendor that ships PowerShell scripts as an integral part of your offering (not just cmdlets,) you should absolutely expect that your users will want to run them. It would be a poor user experience if they had to install your product, and then change their execution policy when they try to use it. There’s also the very real threat of them just trying to make the message go away and picking a needlessly lax execution policy (such as Unrestricted.)

In this situation, we recommend that:

• You sign your scripts with a real Authenticode code signing certificate
• During installation, you change the execution policy to AllSigned if it is currently Restricted. If it is anything but Restricted, leave it alone.
• DO NOT modify the user’s Certificate Store. They will (and should) be prompted the first time they run your scripts to ensure they trust your signing certificate.
• If your installer supports silent installation, offer an option to not modify the execution policy.

To clarify the “leave it alone” point – a non-default execution policy has been put there for a reason. While you might want to increase security to change the execution policy to AllSigned, it is more likely that you will inadvertently break other installed products, or parts of their IT infrastructure that depends on unsigned scripts.

If you do not have a code signing certificate, we recommend getting one! If you cannot, then your installer should prompt the user to change the execution policy to RemoteSigned if it is currently Restricted. If it is anything but Restricted, leave it alone.

“<This product> includes scripts that help you <manage Active Directory, etc.> Your current PowerShell script execution policy will prevent these scripts from running. Would you like to update the execution policy to allow these scripts to run?” ([Yes – Default] / No / Cancel)

Your product itself depends on PowerShell scripts

In this case, PowerShell scripts are simply an implementation language, just like C#, C++, or assembly language. Since you are only running scripts that you wrote, use the PSExecutionPolicyPreference environment variable to change the execution policy for the scope of your application only. RemoteSigned (as opposed to AllSigned) is the best option in this situation so that your application doesn’t need to prompt the user. If your application offers the ability to run random scripts (or launch a PowerShell console,) ensure that you clear your PSExecutionPolicyPreference variable before doing so.

Now what about Exchange?

From their design and user research, they know that a vast majority of their user base will write their own scripts, or run scripts from the community. When they do that, they will ultimately get our execution policy warning, and be forced to make a decision. The most secure decision they can make is the RemoteSigned execution policy, so the Exchange installer makes that decision on their behalf.

Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation

The “Restricted” execution policy isn’t intended to be something that PowerShell users live with forever. It’s a safe default that protects non PowerShell users from being impacted by PowerShell-based malware.

For example, many home users had never used VBScript, but still got bitten by the flurry of WSH-based viruses that got mailed to them. PowerShell’s Restricted execution policy solves this. To an attacker, a computer that has never used PowerShell is the same as a computer that doesn’t have PowerShell installed at all. And since attackers look to affect the largest number of computers possible, PowerShell becomes a less attractive vehicle for their attack. That, in turn, makes PowerShell users safer too. Given all of PowerShell’s security barbs, an attacker is better off using executables or other popular scripting languages as an attack vehicle.

So in light of all this, the Exchange team updates the execution policy to RemoteSigned by our recommendation. If you are an application that uses PowerShell support, you probably fit into one of these situations:

You expect the vast majority of your users to run your scripts

If you are a vendor that ships PowerShell scripts as an integral part of your offering (not just cmdlets,) you should absolutely expect that your users will want to run them. It would be a poor user experience if they had to install your product, and then change their execution policy when they try to use it. There’s also the very real threat of them just trying to make the message go away and picking a needlessly lax execution policy (such as Unrestricted.)

In this situation, we recommend that:

• You sign your scripts with a real Authenticode code signing certificate
• During installation, you change the execution policy to AllSigned if it is currently Restricted. If it is anything but Restricted, leave it alone.
• DO NOT modify the user’s Certificate Store. They will (and should) be prompted the first time they run your scripts to ensure they trust your signing certificate.
• If your installer supports silent installation, offer an option to not modify the execution policy.

To clarify the “leave it alone” point – a non-default execution policy has been put there for a reason. While you might want to increase security to change the execution policy to AllSigned, it is more likely that you will inadvertently break other installed products, or parts of their IT infrastructure that depends on unsigned scripts.

If you do not have a code signing certificate, we recommend getting one! If you cannot, then your installer should prompt the user to change the execution policy to RemoteSigned if it is currently Restricted. If it is anything but Restricted, leave it alone.

“<This product> includes scripts that help you <manage Active Directory, etc.> Your current PowerShell script execution policy will prevent these scripts from running. Would you like to update the execution policy to allow these scripts to run?” ([Yes – Default] / No / Cancel)

Your product itself depends on PowerShell scripts

In this case, PowerShell scripts are simply an implementation language, just like C#, C++, or assembly language. Since you are only running scripts that you wrote, use the PSExecutionPolicyPreference environment variable to change the execution policy for the scope of your application only. RemoteSigned (as opposed to AllSigned) is the best option in this situation so that your application doesn’t need to prompt the user. If your application offers the ability to run random scripts (or launch a PowerShell console,) ensure that you clear your PSExecutionPolicyPreference variable before doing so.

Now what about Exchange?

From their design and user research, they know that a vast majority of their user base will write their own scripts, or run scripts from the community. When they do that, they will ultimately get our execution policy warning, and be forced to make a decision. The most secure decision they can make is the RemoteSigned execution policy, so the Exchange installer makes that decision on their behalf.

Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation

The “Restricted” execution policy isn’t intended to be something that PowerShell users live with forever. It’s a safe default that protects non PowerShell users from being impacted by PowerShell-based malware.

For example, many home users had never used VBScript, but still got bitten by the flurry of WSH-based viruses that got mailed to them. PowerShell’s Restricted execution policy solves this. To an attacker, a computer that has never used PowerShell is the same as a computer that doesn’t have PowerShell installed at all. And since attackers look to affect the largest number of computers possible, PowerShell becomes a less attractive vehicle for their attack. That, in turn, makes PowerShell users safer too. Given all of PowerShell’s security barbs, an attacker is better off using executables or other popular scripting languages as an attack vehicle.

So in light of all this, the Exchange team updates the execution policy to RemoteSigned by our recommendation. If you are an application that uses PowerShell support, you probably fit into one of these situations:

You expect the vast majority of your users to run your scripts

If you are a vendor that ships PowerShell scripts as an integral part of your offering (not just cmdlets,) you should absolutely expect that your users will want to run them. It would be a poor user experience if they had to install your product, and then change their execution policy when they try to use it. There’s also the very real threat of them just trying to make the message go away and picking a needlessly lax execution policy (such as Unrestricted.)

In this situation, we recommend that:

• You sign your scripts with a real Authenticode code signing certificate
• During installation, you change the execution policy to AllSigned if it is currently Restricted. If it is anything but Restricted, leave it alone.
• DO NOT modify the user’s Certificate Store. They will (and should) be prompted the first time they run your scripts to ensure they trust your signing certificate.
• If your installer supports silent installation, offer an option to not modify the execution policy.

To clarify the “leave it alone” point – a non-default execution policy has been put there for a reason. While you might want to increase security to change the execution policy to AllSigned, it is more likely that you will inadvertently break other installed products, or parts of their IT infrastructure that depends on unsigned scripts.

If you do not have a code signing certificate, we recommend getting one! If you cannot, then your installer should prompt the user to change the execution policy to RemoteSigned if it is currently Restricted. If it is anything but Restricted, leave it alone.

“<This product> includes scripts that help you <manage Active Directory, etc.> Your current PowerShell script execution policy will prevent these scripts from running. Would you like to update the execution policy to allow these scripts to run?” ([Yes – Default] / No / Cancel)

Your product itself depends on PowerShell scripts

In this case, PowerShell scripts are simply an implementation language, just like C#, C++, or assembly language. Since you are only running scripts that you wrote, use the PSExecutionPolicyPreference environment variable to change the execution policy for the scope of your application only. RemoteSigned (as opposed to AllSigned) is the best option in this situation so that your application doesn’t need to prompt the user. If your application offers the ability to run random scripts (or launch a PowerShell console,) ensure that you clear your PSExecutionPolicyPreference variable before doing so.

Now what about Exchange?

From their design and user research, they know that a vast majority of their user base will write their own scripts, or run scripts from the community. When they do that, they will ultimately get our execution policy warning, and be forced to make a decision. The most secure decision they can make is the RemoteSigned execution policy, so the Exchange installer makes that decision on their behalf.

Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation

The “Restricted” execution policy isn’t intended to be something that PowerShell users live with forever. It’s a safe default that protects non PowerShell users from being impacted by PowerShell-based malware.

For example, many home users had never used VBScript, but still got bitten by the flurry of WSH-based viruses that got mailed to them. PowerShell’s Restricted execution policy solves this. To an attacker, a computer that has never used PowerShell is the same as a computer that doesn’t have PowerShell installed at all. And since attackers look to affect the largest number of computers possible, PowerShell becomes a less attractive vehicle for their attack. That, in turn, makes PowerShell users safer too. Given all of PowerShell’s security barbs, an attacker is better off using executables or other popular scripting languages as an attack vehicle.

So in light of all this, the Exchange team updates the execution policy to RemoteSigned by our recommendation. If you are an application that uses PowerShell support, you probably fit into one of these situations:

You expect the vast majority of your users to run your scripts

If you are a vendor that ships PowerShell scripts as an integral part of your offering (not just cmdlets,) you should absolutely expect that your users will want to run them. It would be a poor user experience if they had to install your product, and then change their execution policy when they try to use it. There’s also the very real threat of them just trying to make the message go away and picking a needlessly lax execution policy (such as Unrestricted.)

In this situation, we recommend that:

• You sign your scripts with a real Authenticode code signing certificate
• During installation, you change the execution policy to AllSigned if it is currently Restricted. If it is anything but Restricted, leave it alone.
• DO NOT modify the user’s Certificate Store. They will (and should) be prompted the first time they run your scripts to ensure they trust your signing certificate.
• If your installer supports silent installation, offer an option to not modify the execution policy.

To clarify the “leave it alone” point – a non-default execution policy has been put there for a reason. While you might want to increase security to change the execution policy to AllSigned, it is more likely that you will inadvertently break other installed products, or parts of their IT infrastructure that depends on unsigned scripts.

If you do not have a code signing certificate, we recommend getting one! If you cannot, then your installer should prompt the user to change the execution policy to RemoteSigned if it is currently Restricted. If it is anything but Restricted, leave it alone.

“<This product> includes scripts that help you <manage Active Directory, etc.> Your current PowerShell script execution policy will prevent these scripts from running. Would you like to update the execution policy to allow these scripts to run?” ([Yes – Default] / No / Cancel)

Your product itself depends on PowerShell scripts

In this case, PowerShell scripts are simply an implementation language, just like C#, C++, or assembly language. Since you are only running scripts that you wrote, use the PSExecutionPolicyPreference environment variable to change the execution policy for the scope of your application only. RemoteSigned (as opposed to AllSigned) is the best option in this situation so that your application doesn’t need to prompt the user. If your application offers the ability to run random scripts (or launch a PowerShell console,) ensure that you clear your PSExecutionPolicyPreference variable before doing so.

Now what about Exchange?

From their design and user research, they know that a vast majority of their user base will write their own scripts, or run scripts from the community. When they do that, they will ultimately get our execution policy warning, and be forced to make a decision. The most secure decision they can make is the RemoteSigned execution policy, so the Exchange installer makes that decision on their behalf.

Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation