On Henrik Nilson’s blog I found a link to a session from Tech-Ed: Technical Overview of Microsoft Forefront Identity Manager 2010 R2 It’s definitely worth watching. If you’re in a hurry though, here’s a brief summary:

• Support for Extranet Password Reset (other browsers/platforms, not domain-joined)
• Reporting: group membership and object change history
• Extensible MA framework
• Performance improvements
• Best Practices Analyzer
• Add-in Support for Outlook 2010 x86 & x64
• Support for SharePoint 2010

Password Reset

Very neat: support for password resets from PC’s which are not joined to the domain! So this means the extranet password reset scenario is added to FIM 2010 R2! And because no fancy ActiveX is used this should work just fine from other browsers/platforms as well.

This extranet scenario is made available through a new ASP.net password registration/reset portal. This portal is not based upon Sharepoint. They also added the option to add an additional Q/A gate for people resetting their password externally. You could see these as coming from an untrusted location and requiring to answer more questions than someone doing it from on your corporate LAN.

Reporting

This functionality will be made available through a custom FIM MP for SCSM. The SCSM data warehouse is a requirement. If you don’t have one, you’ll be allowed to use one without additional licensing costs.

Extensible MA Framework

Outlook 2010 & Sharepoint 2010 support

Introduction

Lately a colleague of mine was struggling with the following: he wanted a script to be ran from within a Startup Script GPO. Now the problem he was encountering was the following Security Warning from PowerShell:

In words:

Security Warning
Run only scripts that you trust. While scripts from the Internet can be useful, this script can potentially harm your
computer. Do you want to run \\file.setspn.com\scripts\script.ps1?
[D] Do not run  [R] Run once  [S] Suspend  [?] Help (default is "D"):

Now if you have to run something like this occasionally, you can type R and get on it with it. However if this is a script which has to automatically run at startup, this will be a showstopper. So here is some additional information on how to avoid these warnings.

I didn’t tested this in the context of a computer starting up and executing such a script. I just tested this from the Administrator point of view: you run a PowerShell script from a share and you want to avoid that warning. Now what? I will briefly explain Execution Policies and Execution Policy Scopes before actually presenting a solution.

PowerShell Execution Policies

As most of us know by now, PowerShell comes with an execution policy. This policy define which scripts can ran and from which location. By default it’s configured to restricted:

In words:

File \\file.setspn.com\scripts\script.ps1 cannot be loaded because the execution of scripts is disabled on this system.
Please see "get-help about_signing" for more details.
At line:1 char:37
+ \\file.setspn.com\scripts\script.ps1 <<<<
    + CategoryInfo          : NotSpecified: (:) [], PSSecurityException
    + FullyQualifiedErrorId : RuntimeException

However we can easily change the policy to one of the following options:

• Restricted: no scripts
• AllSigned: only signed scripts
• RemoteSigned: local [+detected as local intranet] scripts and signed scripts remotely
• Unrestricted: all scripts but comes with warnings when running from a share
• Bypass: all scripts, no warnings

If you want a full explanation on each of these policies, check TechNet: about_Execution_Policies

PowerShell Execution Policy Scope

Now if you changed the above policy using the Set-ExecutionPolicy Policy command, you changed it for everyone running PowerShell scripts on the current machine. Did you know there is an alternative? You can actually specify a scope using the –scope parameter! This can come in very handy when you just want to open up PowerShell temporary for the installation of a product. The following scopes exist:

• Process: affects only the current PowerShell session
• CurrentUser: affects only the current user
• LocalMachine: affects all users on the current computer

If you want a full explanation on each of these scopes, check TechNet: about_Execution_Policies There’s also additional info available if you want to control this by using GPO.

Determing The Active PowerShell Execution Policy

Using the Get-ExecutionPolicy command you can get the current policy, however if you add the –list parameter you can see where it’s coming from:

Now after running Set-ExecutionPolicy –Scope Process Unrestricted

Now the advantage is that whenever this PowerShell session is closed, the overall policy remains to what is was before my modification.

Getting Rid Of the Warning

All of the options below will explain how you can get rid of the warning when execution a script from an UNC path. Between [] I’ve added the PowerShell execution policies this is working with. The PowerShell script I’m running is located on \\file.setspn.com\scripts and it only contains one line: “write-host –forefgroundcolor green “script executed successfully””.

Option 1: use a shortname in the path [RemoteSigned/Unrestricted]

Why does this work?

By default IE7 and up are configured to automatically detect intranet network. This one checkbox actually is equivalent to checking the 3 options below it. Because we use a UNC path with a short name (\\file), it’s detected as an Intranet and hence no warning is displayed. However once you use a FQDN (\\file.setspn.com), this detection does not work. Reference: Enabling "Automatically Detect Intranet Network" on a domain member computer will enable all the three Intranet Options automatically.

Do we like this? I don’t. I hate NetBIOS names. On to the next option

Option 2: Specify Local Intranet Sites [RemoteSigned/Unrestricted]

The security warning only comes up when the script is ran from an untrusted location, we can add the UNC path to the local intranet. We can do this using one of the following formats:

1. \\*.setspn.com
2. file://*.setspn.com
3. \\file.setspn.com
4. file://file.setspn.com
5. *.setspn.com
6. file.setspn.com

The first 4 options will only affect files accessed from UNC paths, however option 5 & 6 will also involve HTTP/HTTPs traffic. Option 1 & 2 are in fact the same. The same goes for option 3 & 4. Whenever you enter an UNC path like \\location it will automatically be converted to file://location by IE. After adding \\*.setspn.com:

The script now runs just fine:

Option 3: Copy The Script Locally [RemoteSigned/Resctricted]

Obviously this is not applicable in certain scenario’s, but as a quick work around it’s a possibility.

Option 4: Sign your scripts [AllSigned/RemoteSigned/Resctricted]

Another possibility is to sign your scripts. A detailed guide is out of the scope of this post, a good description of the process can be found here: Scott Hanselman: Signing PowerShell Scripts

Option 5: Use The Bypass ExecutionPolicy [Resctricted/AllSigned/RemoteSigned/Resctricted]

All of the above options (beside #1) require you to do some modifications. There’s also a way to just suppress these warnings: the Bypass exeuction policy! I think you can apply it in one of the following ways:

1. Set-ExecutionPolicy Bypass
2. Set-ExecutionPolicy Bypass –Scope Process
3. Powershell.exe –ExecutionPolicy Bypass –file \\file.setspn.com\script.ps1

Option 1 just doesn’t feel right. I myself would definitely go for option 2 or 3. They are more or less equivalent. Option 3 is ideally for calling a PowerShell script from within a bat file. Option 2 is just neat as it’s only active temporarily.

Conclusion

I’m not favoring one of the above options. I think PowerShell execution policies should be part of the Workstation/Server design. A given policy should be decided upon and pushed through GPO. Once that baseline is established, I would choose one of the above options to make a certain script work in the given scenario.

Like if RemoteSigned would be active on workstations, I would consider adding the UNC path to the Local Intranet sites. On the other hand if I would be administering servers (RemoteSigned active) and I’d have a script which I have to run just once, I would consider changing the execution policy to Bypass just for this PowerShell.exe instance (-scope process).

Happy PowerShelling!