The Deployment Guys

Enterprise Management of ActiveX Controls using ActiveX Installer Service

Lutz Seidemann — Sun, 16 Jun 2013 09:01:02 GMT

The ActiveX Installer Service (AXIS) is a Windows technology that enables the installation of ActiveX controls to a standard user in the enterprise. It consists of a Windows service, a Group Policy administrative template, and a few changes in Internet Explorer behavior.

Many organizations must install ActiveX controls on their desktops in order to ensure that a variety of programs that they must use on a daily basis will work properly. However, most ActiveX controls must be installed by a member of the Administrators group, and many organizations have configured or want to configure their users to run as standard users, which are non-administrative users that are members of the Users group. As a result, organizations often have to repackage and deploy the ActiveX controls to the users. In addition, many of these ActiveX controls must be regularly updated. Many organizations find this to be difficult and costly to manage for standard users.

With Windows 7/8 the ActiveX Installer Service is a native OS service and you can easily deploy and update ActiveX controls to your standard user environments. The ActiveX Installer Service enables you to leverage Group Policy to define and manage approved host URLs that standard users can use to install ActiveX controls in a locked-down environment. For more information about AXIS, see: http://technet.microsoft.com/en-us/library/cc721964.aspx.

Here is how ActiveX Installer Service works :

Define a list of explicitly approved host URLs
AxIS checks Group Policy Object (GPO) to see URL is approved
Internet Explorer asks AxIS to install the ActiveX
No admin credentials required for install if approved
If not approved, administrator credentials required for install
Only installs ActiveX controls with a .cab, .dll, or .ocx file extension

AxInstallerService in Windows allows the corporate administrator to manage ActiveX controls while maintaining a strong security posture, by having users run as standard user with default file system settings. AXIS provides Group Policy options to configure trusted sources of ActiveX controls and a broker process to install controls from those trusted sources on behalf of standard users. The key benefit is that you can maintain a non-administrative security posture on user workstations along with centralized administrative control. AXIS relies on the IT administrator to identify trusted sources (typically Internet or intranet URLs) of ActiveX controls.

When an object tag directs Internet Explorer to invoke a control, AXIS takes the following steps:

Checks that the control is installed. If not, it must be installed prior to use
Checks the AXIS policy setting to verify if the control is from a trusted source
The specific check matches the host name of the URL specified in the CODEBASE attribute of the object tag against the list of trusted locations specified in policy
Downloads and installs the control on the user’s behalf

Some security zones settings configure the ability for computers to execute and/or download ActiveX controls. However, even if Internet Explorer allows an ActiveX control to be downloaded from the web site, the ActiveX control can only be installed from an elevated process or administrative account. One of the goals for enterprises is to only provide end users standard, non-administrative access to their operating system. This means that ActiveX controls downloaded from web sites – regardless of the web site’s security zone – cannot be installed by the end users.

With Windows 7/8 and beyond, AXIS is a native Windows service that will install ActiveX controls on behalf of end-users. Enterprises can maintain a list of approved web sites, implemented via Group Policy, that will cause AXIS to install any required ActiveX controls for the end-user. Further, AXIS can be configured to install ActiveX controls from all Trusted Sites.

The advantage of using AXIS over an Software Distribution tool is that no packaging of ActiveX controls is required, which significantly reduces the amount of time needed to get an ActiveX control installed in production. Group Policy based administration enables rapid changes to the deployed computers. Leveraging AXIS involves some additional management, specifically the management of a Group Policy object to add specific sites to leverage AXIS. The control of ActiveX installation and functional state can be managed in enterprises via Active Directory Group Policy.

Policy Settings	Scope	Policy Path
Turn off ActiveX Opt-In Prompt	User, Machine	Windows Components\Internet Explorer
Only use the ActiveX Installer Service for installation of ActiveX controls	User, Machine	Windows Components\Internet Explorer
Only allow approved domains to use ActiveX without prompt	User, Machine	Windows Components\Internet Explorer\Internet Control Panel\Security\PER ZONE
Disable Per-User Installation of ActiveX Controls	User, Machine	Windows Components\Internet Explorer

Turn off ActiveX Opt-In prompt: This policy setting allows you to turn off the ActiveX Opt-in prompt. The ActiveX Opt-in prevents websites from loading any COM object without prior approval. If a page attempts to load a COM object that Internet Explorer has not used before, an Information bar will appear asking the user for approval. If you enable this policy setting, the ActiveX Opt-in prompt will not appear. Internet Explorer does not ask the user for permission to load a control, and will load the ActiveX if it passes all other internal security checks. If you disable or do not configure this policy setting, the ActiveX Opt-In prompt will appear.

Only use the ActiveX Installer Service for installation of ActiveX controls:
This policy setting allows you to specify how ActiveX controls are installed. If you enable this policy setting, ActiveX controls will only install if the ActiveX Installer Service is present and has been configured to allow ActiveX controls to be installed. If you disable or do not configure this policy setting, ActiveX controls, including per-user controls, will be installed using the standard installation process.

Disable Per-User Installation of ActiveX Controls: This policy setting allows you to disable the per-user installation of ActiveX controls. This policy only affects ActiveX controls that can be installed on a per-user basis. If you enable this policy setting, ActiveX controls cannot be installed on a per-user basis. If you disable or do not configure this policy setting, ActiveX controls can be installed on a per-user basis.

Configuring the ActiveX Installer Service

The ActiveX Installer Service is enabled by default in Windows 7 /8 , you only need GPMC to configure it. You must configure the ActiveX Installer Service settings by using an administrative template in Group Policy. The administrative template consists of a list of approved installation sites, which the ActiveX Installer Service uses to determine whether an ActiveX control can be installed. We recommend Domain policies over Local policies.

To configure the ActiveX Installer Service using local GPMC (similar steps for Domain Policy)

Press Windows Key + R to open the Run command.
Type mmc, and then click OK.
In the File menu, click Add/Remove Snap-in.
In the Add/Remove Snap-ins dialog box, select Group Policy Management Console, and then click Add.
In the Select Group Policy Object dialog box, accept the default setting of the local computer or click Browse to configure a remote computer, and then click Finish.
In the Add/Remove Snap-ins dialog box, click OK.
In the console tree, expand Local Computer Policy, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click ActiveX Installer Service.
In the details pane, click Approved Installation Sites for ActiveX Controls to edit
In the Approved Installation Sites for ActiveX Controls Properties dialog box, select Enabled, and then click Show next to Host URLs.
In the Show Contents dialog box type the name for the URL where you want to allow ActiveX controls to be installed
Type the values for the four ActiveX Installer Service host URLs settings.
Click OK
In the details pane, click Establish ActiveX installation policy for sites in Trusted zones to Edit.
Make your selection for the Trusted zones
Click OK to close

When you add a URL, you can specify comma-delimited values that detail the settings for the ActiveX Installer Service.
You can configure four values:

Installing ActiveX controls that have trusted signatures
Installing signed ActiveX controls
Installing unsigned ActiveX controls
HTTPS error exceptions

ActiveX Recommended Practices

▪ Only install ActiveX controls from reputable organizations -
We recommend that you only install ActiveX controls from publishers that you know and trust. The ActiveX Installer Service does not determine whether the host presenting the ActiveX control is connected to a secure network. Ensuring that you only install ActiveX controls from reputable publishers will help mitigate this threat.

▪ Deploy commonly used ActiveX controls -
We recommend that you deploy ActiveX controls that are commonly used in your environment by using your organization's application deployment method. Many users today use laptops to connect to multiple networks, including wireless hot spots. A malicious proxy at an insecure network could attempt to trick the ActiveX Installation Service by redirecting it to a host with malicious software that represents itself as a commonly used ActiveX control. Ensuring that you deploy commonly used ActiveX controls for your users will help mitigate this threat.

▪ Only use HTTPS host URLs -
We recommend that you only modify the value for HTTPS error exceptions to require the connection to pass all verification checks (0). If a remote users connects to an insecure wireless network, and the proxy attempts to redirect the connection, this setting will ensure that the ActiveX control installation will fail since the certificate will be invalid.

▪ Consolidate ActiveX controls to a central server -
We recommend that you consolidate the ActiveX controls you use in your organization to a central server. The location where a Web site hosts an ActiveX control is called a CODEBASE. Normally, the CODEBASE is specified in the Web page, and the installation process retrieves the ActiveX control from that location.
In managed enterprises, you can use Group Policy to override the CODEBASE that is specified within the Web page to redirect to an internal server. Using this setting allows you to easily manage which ActiveX controls users can install by consolidating the ActiveX controls onto a central server; if the server is an HTTPS server, you also satisfy the previous recommended practice, only use HTTPS host URLs.
You can configure a common Group Policy setting to redirect all ActiveX control installations to a central server in your organization. You can do this by using the CodeBaseSearchPath registry key. For more information on the CodeBaseSearchPath see Implementing Internet Component Download http://go.microsoft.com/fwlink/?LinkId=90677

AXIS Implementation Checklist

Gather ActiveX controls - You can assess which controls, if any, are appropriate to use within your organization. You may need to gather an inventory of existing ActiveX controls already in production use. The Microsoft Assessment and Planning Toolkit or Application Compatibility Manager as part of the Windows 8 ADK will help for the inventory.
Create and implement Group Policies

Most Common Controls

More Information about ActiveX can be found:

ActiveX Installer Service in Windows 7 Technical Reference
http://technet.microsoft.com/en-us/library/ee247410(v=WS.10).aspx
Administering the ActiveX Installer Service in Windows 7
http://technet.microsoft.com/en-us/library/dd631688(v=WS.10).aspx
Fixing ActiveX Installation Compatibility Issues for Standard Users
http://msdn.microsoft.com/en-us/library/windows/desktop/ff966518(v=vs.85).aspx

This post is based on the work of Steve Campbell (Architect with Microsoft Consulting Services US ) and was contributed by Lutz Seidemann, a Solution Architect with Microsoft Consulting Services – World Wide Client Center of Excellence.

The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Signing Windows 8 applications using an Internal PKI

DeploymentGuys — Fri, 14 Jun 2013 08:22:00 GMT

So – your development cycles have been completed and now you are ready to deploy the much anticipated Windows 8 based application that you have developed to your clients. You will quickly realize that the deployment of your newly created Windows 8 application cannot happen until the appx assembly has been signed. All methods of deployment (Windows Store, PowerShell or System Center 2012 Configuration Manager) require the application to be signed using a certificate issued by a trusted source before you can deploy it.

If your application was developed with the intention of staying within the corporate landscape, then you may use a certificate issued by an internally hosted trusted CA. A lot of documentation is available about the requirements of the certificate issued, but a how-to guide was not available until now. This blog post will walk you through the steps required to install an internally developed application to production systems.

The screen captures in this blog post are performed using Windows Server 2012 Domain Controller, Windows Server 2012 Certificate Authority, Visual Studio 2012 and Windows 8 Enterprise. The procedures for Windows Server 2008 R2 vary slightly, but the same certificate requirements can been completed.

The diagram below identifies the workflow that this blog post will walk you through.

Get the Certificate

Visual Studio will validate the certificate used to sign the app in the following ways:

Verifies the presence of the Basic Constraints extension and its value, which must be either Subject Type=End Entity or unspecified.
Verifies the value of the Enhanced Key Usage property, which must contain Code Signing and may also contain Lifetime Signing. Any other EKUs are prohibited.
Verifies the value of the KeyUsage (KU) property, which must be either Unset or DigitalSignature.
Verifies the existence of a private key exists.
Verifies whether the certificate is active, hasn’t expired, and hasn't been revoked.

Create the Template

The built-in Windows 2008 R2 or Windows 2012 templates will not allow the creation of a certificate which meets all of these requirements. A new template must be created which allows the issuance of a properly configured certificate.

Load an MMC and add the Certificate Authority and Certificate Templates
Select Certificate Templates > Right Click on Code Signing > Duplicate Template
On the Compatibility tab · Change Certificate Authority to Windows Server 2008 R2 or Higher · Change the Certificate Recipient to Windows 7/Server 2008 R2 or Higher Note: These two changes allow the Basic Constraints Extension to be enabled.
On the Request Handling tab · Check the box to allow private key to be exported
On the General tab · Provide a useful name for this new template
On the Extensions tab · Click on the Application Policies Extension and verify Code Signing Note: For additional security, you can also add the Lifetime Signing extension to this template to ensure the signing certificate is no longer valid after expiration.
On the Extensions tab · Click on Basic Constraints and click Edit and check the box to Enable this extension. Note: If this checkbox is grayed out, make sure the certificate template is set properly on the Compatibility tab
On the Subject Name tab · Select the Supply in the request radio button and Click OK on the warning
On the Security tab · Add a user or group to allow them to enroll the certificate. The must have the Read and Enroll permissions.
In the MMC, expand Certificate Authority > {CAName} > Right Click Certificate Templates > New > Certificate Template to Issue Select the Template Name just created > Click OK
Notice the APPX Code Signing Template is now listed on the CA under Certificate Templates

Request the Certificate

The certificate template has been created and now must be requested to generate a .cer file that will be placed in the local store on the computer the request is made from. It doesn’t matter which system makes the request because the .cer is immediately used to generate the .pfx file needed to sign the application.

Open an MMC and add the certificates snap-in and select My User account radio button. In the MMC > Expand Certificates – Current user > Personal > Right Click on Certificates > All Tasks > Request New Certificate Note: The computer store can be used as well, but the computer account would need permission to enroll the certificate. In this example, we only added permissions for the application developers group.
Click Next on the Before You Begin screen
On the Select Certificate Enrollment Policy screen · Ensure Active Directory Enrollment Policy is selected · Click Next
On the Request Certificates screen · Click on the link below the APPX Code Signing template to configure additional settings Note: The Enroll button cannot be selected until the missing settings are configured
On the Certificate Properties screen · Under Subject Name the type should be Common Name · Value must be the same as the Publisher value in the Visual Studio 2012 package.appxmanifest · Click Add Note: The CN= is automatically appended and is not required when typing the Publisher Name. In this example just ContosoAppDev was entered in the value textbox.
On the Request Certificates screen · APPX Code Signing is selected · Click Enroll
On the Certificate Installation Results screen · Check the status · Click finish
On the Certificates – Current User MMC · The new certificate will be listed

Export to PFX

Visual Studio requires the .pfx format to sign the application. In the previous step, we generated a .cer file which is located in the user store. We need to convert that .cer to a .pfx in preparation for signing.

On the Certificates – Current User MMC · Right Click the New Certificate > Click All Tasks > Click Export
On the Welcome screen · Click Next
On the Export Private key screen · Click ‘Yes, export the private key’ · Click Next
On the Export File Format screen · Ensure Personal Information Exchange is selected · Ensure Include all certificates in the certification path if possible is checked · Check Export all extended properties · Click Next
On the Security screen · Select the Password checkbox · Enter a password (this will be needed during import into Visual Studio 2012) · Click Next
On the File to Export screen · Provide a path and filename · Click Next
On the Completing the Certificate Export Wizard screen · Click Next
On the Certificate Export Wizard message box · Click OK

Sign the Application

Open Windows Explorer to the location where the pfx file was saved. Note: The pfx file should be moved to a computer with VS 2012 installed.
Open Visual Studio 2012 project to be signed · double click the package.appxmanifest · Click Choose Certificate…
On the Choose Certificate screen · Click Configure Certificate > Select from File…
On the Select File screen · Navigate to and select the exported PFX file · Click Open
On the Enter Password screen · Enter Password · Click OK
On the Choose Certificate screen · Click OK

Package the signed APPX

We have created the .pfx file needed to sign the application in the previous steps, so now we can sign our application.

Open Visual Studio 2012 project to be packaged
Inside the project · Right click the Project · Click Rebuild
Inside Solution Explorer · Right click the solution to be packaged · Click Store · Click Create App Package
On Create Your Package screen · Select No · Click Next
On the Select and Configure Packages screen · Specify the path for the package to be placed · Click Create
On the Package Creation Completed screen · Click OK Note: You may click on the link provided to navigate to the location the package was placed.

Configure Group Policy

In order to deploy a Windows 8 application using Side loading, the computer receiving the package must either have a developer license (used for testing purposes only) or appropriate local/group policy settings to ensure the applications which are trusted can be installed.

Open Group Policy Management · Right click where you want to link the new Group Policy · Click Create a GPO in this domain and Link it here… Note: The Windows 8 systems must be located within the location where the new GPO is being linked
On the new GPO screen · Name the GPO appropriately · Click OK
On the GPMC · Right click the new policy · Click Edit…
On the Group Policy Management Editor screen · Expand Computer Configuration > Policies > Administrative Templates > Windows Components > App Package Deployment · Right Click Allow all trusted apps to install > Click Edit
On Allow trusted apps to install screen · Select Enabled · Click OK

This post was contributed by John Taylor, a Senior Consultant with Microsoft National IT Operational Consulting – US.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Update – Removing Built-in Applications from Windows 8

Ben Hunter — Fri, 07 Jun 2013 18:48:41 GMT

In October last year I published a script that is designed to remove the built-in Windows 8 applications when creating a Windows 8 image. After a reading some of the comments in that blog post I decided to create a new version of the script that is simpler to use. The new script removes the need to know the full name for the app and the different names for each architecture. I am sure you will agree that this name - Microsoft.Bing – is much easier to manage than this - Microsoft.Bing_1.2.0.137_x86__8wekyb3d8bbwe.

The script below takes a simple list of Apps and then removes the provisioned package and the package that is installed for the Administrator. To adjust the script for your requirements simply update the $AppList comma separated list to include the Apps you want to remove.

$AppsList = "Microsoft.Bing" , "Microsoft.BingFinance" , "Microsoft.BingMaps" , "Microsoft.BingNews"`
            , "Microsoft.BingSports" , "Microsoft.BingTravel" , "Microsoft.BingWeather" , "Microsoft.Camera"`
            , "microsoft.microsoftskydrive" , "Microsoft.Reader" , "microsoft.windowscommunicationsapps"`
            , "microsoft.windowsphotos" , "Microsoft.XboxLIVEGames" , "Microsoft.ZuneMusic"`
            , "Microsoft.ZuneVideo" , "Microsoft.Media.PlayReadyClient"

ForEach ($App in $AppsList)
{
    $PackageFullName = (Get-AppxPackage $App).PackageFullName
    if ((Get-AppxPackage $App).PackageFullName)
    {
        Write-Host "Removing Package: $App"
        remove-AppxProvisionedPackage -online -packagename $PackageFullName
        remove-AppxPackage -package $PackageFullName
    }
    else
    {
        Write-Host "Unable to find package: $App"
    }
}

For more information on adding and removing apps please refer to this TechNet article.

This post was contributed by Ben Hunter, a Solution Architect with Microsoft Consulting Services.

Automatically Populate the PATCH Property for the ConfigMgr Client Installation – Script Update

Michael Murgolo — Wed, 05 Jun 2013 02:05:00 GMT

Last October I posted an update to the script to automatically set the PATCH property used by ccmsetup.exe to install client updates during the Configuration Manager client installation in a task sequence. That update was to make the script compatible with ConfigMgr 2012.

Since that time, my colleague Alexey Semibratov pointed out to me that the script did not correctly handle FullMedia deployments correctly. In that scenario, I had assumed that the script could install the client updates directly off the media. This assumption will not work if the media drive letter changes after booting into the new OS.

To overcome this, the new version attached below now uses Alexey’s idea to copy the updates to %OSDisk%\windows\temp\hotfix in all scenarios. The %OSDISK% variable should get set properly in all scenarios when using latest MDT 2012 Update 1 task sequence template.

Follow the October 2012 post for instructions to setup the client package and Chris Nackers’ great blog post for instructions on how to configure this solution.

Update 2013-06-12: In a comment posted to the October 2012 post, a reader had an issue where it appeared that the OSDisk variable did not get set before this script ran. To try to alleviate this, I have made a small change to the script where it now checks to see if OSDisk has a value and if not, calls a ZTIUtility.vbs function to try to set it. The updated script (v1.1.3) is now attached below. This version requires the latest version of ZTIUtility.vbs (from MDT 2012 Update 1 as of this writing).

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

PXE Deployment with Surface Pro

Ben Hunter — Thu, 16 May 2013 20:44:43 GMT

PXE support has been added to Surface Pro as part of the May firmware update. This means that as long as you have the Surface Pro Ethernet Adapter and installed the firmware update you can now perform PXE based deployments to Surface Pro. For detailed guidance on updating firmware on Surface pro please refer to my previous blog post - http://blogs.technet.com/b/deploymentguys/archive/2013/05/14/deploying-drivers-and-firmware-to-surface-pro.aspx.

To perform a deployment from your existing Windows Server 2008 R2 or Windows Server 2012 WDS server you need to do the following:

Attach the Surface Pro Ethernet Adapter to the Surface Pro.
Press and hold the volume down button and then press the power button, continue to hold the volume down button until the Surface starts to boot from the USB key.

A dialog box will appear that states that it is “Checking Media Presence……”. Then it will “Start PXE over IPv4”.

3. When prompted press Enter for network boot service.

The Surface Pro should now connect to your PXE server and allow you to perform a normal deployment.

For further details on Surface Pro deployment please refer to the Surface Pro - Enterprise Deployment Quick Start Guide within the Surface Pro firmware and driver pack that I worked with the Surface Team create.

This post was contributed by Ben Hunter, a Solution Architect with Microsoft Consulting Services.

Deploying Drivers and Firmware to Surface Pro

Ben Hunter — Thu, 16 May 2013 20:44:33 GMT

In the last month the Surface Pro team have started releasing driver and firmware packs that include all on the drivers and firmware required for Surface Pro. This pack is a simple zip file that contains all of the drivers as INF files that can be installed with out requiring an executable, which for those of you that have followed my previous posts will know is the way I like to see drivers provided.

Firmware Deployment

Perhaps the coolest thing about this pack is the fact that it includes firmware that is delivered in the form of a driver package. This is possible due to a UEFI feature called capsule packages. These capsule packages can be installed several ways:

Published via Windows Update
Injected into an offline Windows image
Installed into Windows 8 online

Note - They cannot be installed via Windows Software Update Service (WSUS).

The firmware is exposed to the machine as a device under the firmware node in device manager.

To update the firmware manually simply install the driver package on the machine then Windows will then seamlessly take care of the update process for you, ensuring that the correct firmware is applied. Once installed a flag is set for the loader and on restart all available firmware updates are applied. During the boot process a dialog will appear that states “installing system updates”. If you are deploying the drivers as part of an OS deployment, perhaps with the Microsoft Deployment Toolkit or System Center Configuration Manager 2012 you simply add these firmware drivers to your existing driver deployment methodology and the Windows will handle handle the update process for you.

Driver Deployment

Deploying these drivers as part of your existing OS deployment process is simple, however what happens if you want to update drivers on a Surface Pro that has already been deployed. This is definitely something you will want to do as the Surface team has already delivered a number of significant performance improvements as driver and firmware updates. One option would be to manually right clicking on the device in device manager, and select the appropriate driver to install. However this is a laborious process. It is possible to automate this process using a PowerShell script that calls the PnPUtil utility.

The following script iterates recursively through the pack and installs all of the drivers that it finds:

$ScriptPath = Split-Path -parent $MyInvocation.MyCommand.Definition

$files = get-childitem -path $Scriptpath -recurse -filter *.inf

foreach ($file in $files)

{

Write-host "Injecting driver $file"

pnputil -i -a $file.FullName

}

To use this script extract the driver pack and place the script in top level folder of the extracted zip file. Then execute the script, it will install all drivers (including firmware). This could also be packaged into a System Center Configuration Manager package and deployed to existing machines.

This post was contributed by Ben Hunter, a Solution Architect with Microsoft Consulting Services.

Supporting Windows 8 Mail App in the Enterprise

Lutz Seidemann — Tue, 14 May 2013 21:21:00 GMT

In a recent project we faced an interesting problems using the Windows 8 Mail App.

Windows 8 include a built-in email app named Mail (also referred to as Windows 8 Mail or the Windows 8 Mail app). We used a Standard User Account without any local Admin privileges, logged on to the Domain and tried to add our Exchange information to the mail app. After adding our Account information an error is popping up “To sync username@yourdomainname.com, you will need to change this PC’s settings to match the mail server’s security settings.”

After some investigation about this error we found out there are few settings Enterprises need to prepare before using the mail app in an environment with logged down user rights.

The Windows 8 Mail to allows users using ActiveSync (EAS) for Exchange synchronization. If you add your account to the Mail application your Exchange policies will pushed down and the stronger policy will take presence (http://blogs.technet.com/b/exchange/archive/2012/11/26/supporting-windows-8-mail-in-your-organization.aspx). If your EAS is stronger than your Domain or local policy the Windows Policy Engine requires admin access to apply policy changes, since non-admins are not allowed to make changes to computer/account configurations, you will get the issue documented above.

In a next step you have to compare the policy that is applied on the device(s) against what is being requested by the Exchange server.

Control the corresponding Group Policy (Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options /) to have the same settings as you have configured in Exchange. If both are identical you can add your Exchange Account without getting any popup.

AllowSimpleDevicePassword                                     : Windows Policy Engine would try to apply this policy,
MaxInactivityTimeDeviceLock                                    : Windows Policy Engine would try to apply this policy,
MaxDevicePasswordFailedAttempts                       : Windows Policy Engine would try to apply this policy,
DevicePasswordExpiration                                          : Windows Policy Engine would try to apply this policy,
DevicePasswordHistory                                                 : Windows Policy Engine would try to apply this policy,
RequireDeviceEncryption                                              : Windows Policy Engine would try to apply this policy,
MinDevicePasswordComplexCharacters               : domain accounts, password length and complex characters are not governed by EAS,
MinDevicePasswordLength                                         : domain accounts, password length and complex characters are not governed by EAS,

This post was contributed by Lutz Seidemann, a Solution Architect with Microsoft Consulting Services.

Windows 8 – Supporting proxy services with Static Configurations, Web Hosted PAC files and Domain Policy Configured Proxy

Scott Culbertson — Wed, 08 May 2013 19:32:07 GMT

Many companies have started using Windows 8 and have noticed with some of the new features there are times when things just don’t seem to work the way they expected them too; this was due to configuration needs and not actual issues in many cases. We have found this is normally due to some additional configurations that are required to enable the newer features and applications that have been introduced with the new OS.

I would like to focus on one that I have been putting some extra effort towards to help customers get the best experience they can when the enterprise has proxy services enabled and they see issues such as the Windows 8 apps and basic services are not communicating with web services.

Sometimes communities identify issues and is important that we help improve the user experience when issues are identified. There are a couple articles currently articles addressing some of the original issues. Specifically the need to use the NETSH commands to correct the WINHTTP Proxy service; see the reference articles within this blog for links to them. This include transitioning to new networks and the use of WPAD for the most robust model for Windows 8.

Note: It is important to also understand before we review these scenarios and options that for the best Windows 8 experience it is recommended to use WPAD to enable all the features of Windows 8 without additional work for the client. Use these links to understand how to implement WPAD and enabling Authenticated Proxy support.

Supporting Articles:

Implementing WPAD: KB2777643

Authenticated Proxy Support: KB2778122

Proxy Service in the Enterprise:

Key Scenarios: Typical results in the following scenarios with “Static Proxy”, “Web Hosted Proxy PAC Files” and “Domain Policy Defined Proxy”, hosted PAC files is the following:

Window 8 Network Location Awareness: NLA is required for Windows 8 applications to function properly by determining that you are connected to the internet by looking for a file called ncsi.txt on the internet and is the feature that tells the Windows 8 applications if your online. When this is working right your Network Icon will reflect your online and when you access Windows 8 Application such as Bing Sports it will identify your access and function properly. Properly define proxy services will enable this.

Windows 8 Applications: In general testing Windows 8 applications will function as designed. Note: This is not a blanket statement for all Windows store application due to the lack of testing. I have tested the normal inbox apps and some additional application downloaded.

The Windows Store Application updates: This feature is functioning while using Static or PAC files when the user is on public networks only. In some cases it has been noticed that the Inbox Windows 8 apps will be able to update while connected to the corporate network. If the updating is needed internally and you must use a PAC file you may wish to look at using WPAD. Another option is to use the PAC file model I describe below.

The Windows Store Catalogue: Can be viewed and searched.

Windows Store Apps Downloads: This feature is functioning while using Static or PAC files when the user is on public networks only to purchase apps and download. If the download is needed internally and you must use a PAC file you may wish to look at using WPAD. Another option is to use the PAC file model I describe below.

Windows Update: For Windows updates it has been observed that Automatic Updates do not work with Proxy configuration but both User Activated updates in the Windows 8 WU and the Classic Update model they will work. Once the computer is on the public network it will be able to receive Automatic Updates or with the user checking for updates.

Note: There is a known Issue for Authenticating Proxies Solutions: You will need to follow the guidance in the KB2778122 for whitelisting certain HTTP address’s listed in article to ensure the best experience while on the corporate network.

Note: Known issue with local installed PAC files: Local install of PAC files will not work for more than Local Browser services.

Enabling these PROXY scenarios:

We will walk through the simplest implementation which also has most limitation to the preferred method and options for configuration of PAC files.

Static Proxy Services:

Note: Only noted to help customers understand chance for negative experience. This is not preferred, this shouldn’t be used unless you are supporting desktop only. I just wanted to make people aware of it. Preferred approach is WPAD and then Web Proxy PAC file

This model is a direct insertion of the proxy server address and port used for communication via Internet Explore through the configuration via “Internet Options” and clicking on “Connections Tab” then “LAN Settings” and setting up your proxy definition under Proxy Server”

Load Internet Explorer and open Settings / Internet Options

With this implementation you will find that as long as your computer is on the proper network where the proxy server can be found your services as described above will work. If the Proxy Server is not locatable the following error will be observed due to WEB services not routing properly. Resolution will be to connect the system back to the proper network.

Put the system back onto the proper network or remove the static proxy setting.

Web Based Proxy PAC File:

Note: Using the following two configuration options in the Proxy path configuration do not work:

If Proxy PAC files need to be used in the enterprise environment using a web hosted service is the preferred method. This can be hosted on the proxy server or any other IIS services hosting the file so it can be accessed by the computer at boot. To do this you need to configure the PROXY setting in the manner below.

This model is a direct insertion of the web server address for the PAC file for communication via Internet Explore through the configuration via “Internet Options” and clicking on “Connections Tab” then “LAN Settings” and setting up your proxy definition under Proxy Server

Load Internet Explorer and open Settings / Internet Options

In this case you will have the expected results I noted above in the top of this Blog. I also want to provide a couple sample PAC files that I have found to help make the user experience work well. I also will discuss a model where you could potentially enable the Windows 8 App Store for downloading applications that was mentioned above where it may potentially not work with PAC files.

Sample PAC file #1:

Net Results will be that your system will function with new Windows 8 Apps but you will not be able to download new apps till the device is placed outside the corporate network. The proxy will be offline and your system will default to standard full internet access allowing the download of the selected applications. If for some reason you have an external Proxy you will need to consider the second sample file for the best results.

This file is the simplest and will identify your host network and then designate the Proxy Server for that network. If the network host is not found it instructs the WINHTTP services to use the default gateway of the computer. While on the company network Windows 8 App Store Downloads may not work but when the computer is on a public network it will be able to download Windows Store Apps.

You can use notepad.exe to create a simple test file, example: Sample1.PAC

//Begin

function FindProxyForURL(url, host)

{

if (isInNet(myIpAddress(), "10.0.0.0", "255.255.255.0"))

return "PROXY ProxyServerName:8080";

else "Proxy Direct";

}

//End

Sample PAC File #2:

Note: This will require corporate review and approval most likely. The purpose of this Script is to enable Windows Application Store Downloads within the corporate network with proxy services or if the company is using an External Web based Proxy Service.

In this scenario you have a Default Gateway on the corporate network that is open to the internet but normal traffic is always processed through the Proxy server. With this configuration we have directed any traffic required to communicate with Microsoft to be allowed to operate through the default gateway and the limited capabilities are now removed and Windows Store Apps will now be successfully downloaded on the corporate network.

You can use notepad.exe to create a simple test file, example: Sample2.PAC

//Begin

function FindProxyForURL(url, host)

{

// variable strings to return

var proxy_online = "PROXY ProxyServer:8080";

var proxy_offline = "DIRECT";

if (shExpMatch(url, "http://*.microsoft.com*"))

{ return proxy_offline; }

if (shExpMatch(url, "https://*.microsoft.com*"))
{ return proxy_offline; }

// Proxy anything else

return proxy_online;

}

//END

Domain Policy Configuration for a PAC File:

This procedure assumes you are familiar will traversing the Group Policy Management tool using either Server 2012 or the Remote Server Administration Toolkit for Windows 8.

First create a policy for Internet Explorer 10 for the proxy configuration under “User Settings” Preference – Control panel settings.

Wizard will pull up and then you can select “Connection” Tab and then “LAN settings” Radio Button

Enter the required Proxy settings and then link the GPO to you target OU

Make sure to select F5 on the Field when you enter the Name so it is accepted.

This will allow you to now set the Proxy GPO on your system.

Additional information for PAC Files Scripting options can be found here: MS TechNet on PAC File Scripting

This post was contributed by Scott Culbertson, a Solution Architect with Microsoft Consulting Services.

USMT Restore Status Notification HTA in Full Operating System

Brad Tucker — Tue, 09 Apr 2013 16:35:15 GMT

In my previous blog entry, I explained my customer’s need for stand-alone USMT Capture and USMT Restore task sequences and their need for a notification box to pop up and let the technicians know the process completed successfully. This post will continue in that vein and discuss the notification HTA for the USMT Restore task sequence.

The requirement was to make a notification box pop up and pause the task sequence until it is acknowledged or closed.

I created a simple HTA that will look for the loadstate.log in the CCM\Logs\SMSTSlog folder based on architecture. As I am sure you are aware, the SMSTSLog folder is where the logs are placed during the task sequence, so they are always guaranteed to be current. It isn’t until the task sequence is closed out that the logs are moved one level up and the SMSTSLog folder removed.

If they are running on a Windows XP machine the path is:

C:\Windows\System32\CCM\Logs\SMSTSLog\loadstate.log.

If they are running on a Windows 7 x64 machine, the path is:

C:\Windows\SysWow64\CCM\Logs\SMSTSLog\loadstate.log

The HTA then parses this log file looking for ‘MIGACTIVITY_SUCCESS’. If this message exists in the log file, the HTA returns the following box…

If it doesn’t exist, they see the following box…

Now that the HTA is functional, I have to put it in the task sequence and make it visible while running inside the full operating system. This is where the fun really begins…

Luckily, we can take advantage of ServiceUi.exe that exists in the Tools\x86 or Tools\x64 folders within the Microsoft Deployment Toolkit package. We can launch this by calling it from %toolroot%.

Placing my HTA file in a folder called CustomScripts underneath the Scripts folder in the toolkit package allows me to use the command line…

%toolroot%\serviceui.exe –process:tsprogressui.exe %systemroot%\system32\mshta.exe %scriptroot%\CustomScripts\USMTRestoreStatus.hta

Here is an example of how to call my HTA using the ServiceUi.exe…

For more information on the use of ServiceUI.exe, see ‘Can I use ServiceUI.exe to launch other programs besides the UDI Setup Wizard?’ on Cameron’s Blog – Cravings of System Center.

USMTRestoreStatus.hta

<html>
< head>
< title>USMT Restore Status</title>
< HTA:APPLICATION
APPLICATIONNAME="USMT Restore Status"
ID="USMTRestoreStatus"
SCROLL="no"/>
< /head>

' *****************
' * Window_OnLoad *
' *****************

Sub Window_OnLoad
'This method will be called when the application loads
   window.resizeTo 600,300
   window.moveto 1,1
   USMTStatus
End Sub

' *****************
' * USMTStatus *
' *****************

Sub USMTStatus
Const ForReading = 1

' Set the search parameter
Set objRegEx = CreateObject("VBScript.RegExp")
objRegEx.Pattern = "MIGACTIVITY_SUCCESS"

' Prepare log file connectivity
Set objFSO = CreateObject("Scripting.FileSystemObject")

' WMI Connectivity
strComputer = "."
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

' Query WMI for processor architecture type
Set colProcessors= objWMIService.ExecQuery ("Select * From Win32_Processor")

' Set log file location based on processor architecture type
For Each objProcessor in colProcessors
If objProcessor.Architecture = 0 Then
Set objFile = objFSO.OpenTextFile("C:\windows\system32\ccm\logs\SMSTSLog\loadstate.log", ForReading)
Else
Set objFile = objFSO.OpenTextFile("C:\windows\syswow64\ccm\logs\SMSTSLog\loadstate.log", ForReading)
End If

' Set initial returnSuccess to 'False'
returnSuccess = False

' Parse the scanstate.log file for search parameters
Do Until objFile.AtEndOfStream
    strSearchString = objFile.ReadLine
    Set colMatches = objRegEx.Execute(strSearchString)
    If colMatches.Count > 0 Then
        For Each strMatch in colMatches
            returnSuccess = True
        Next
    End If
Loop

' Set HTA pop-up box text based on search results
If returnSuccess = True Then
DataArea.InnerHTML = "The user state was SUCCESSFULLY restored.<br><br>PLEASE CLOSE THIS BOX TO END THE TASK SEQUENCE."
Else
DataArea.InnerHTML = "The user state was NOT SUCCESSFULLY restored.<br><br>PLEASE CLOSE THIS BOX TO END THE TASK SEQUENCE."
End If

End Sub

< /script>

</body>
< /html>

USMTRestoreStatus.hta

This post was contributed by Brad Tucker, a Senior Consultant with Microsoft Services, East Region, United States

USMT Capture Status Notification HTA in Full Operating System

Brad Tucker — Tue, 09 Apr 2013 13:48:26 GMT

Recently, I had a customer that wanted separate, stand-alone USMT Capture and USMT Restore task sequences. They had key depot locations that would allow users to drop off an old machine, and have the depot technicians image and restore data to a new device. They would then repurpose the old machine.

Evidently, they had issues with USMT not running successfully or perhaps it was forgotten by the technician in the first place. So they asked for a notification box to pop up and let the technician know the data was, in fact, captured successfully.

The requirement was to make a notification box pop up and pause the task sequence until it is acknowledged or closed.

I created a simple HTA that will look for the scanstate.log in the CCM\Logs\SMSTSlog folder based on architecture. As I am sure you are aware, the SMSTSLog folder is where the logs are placed during the task sequence, so they are always guaranteed to be current. It isn’t until the task sequence is closed out that the logs are moved one level up and the SMSTSLog folder removed.

If they are running on a Windows XP machine the path is:

C:\Windows\System32\CCM\Logs\SMSTSLog\scanstate.log.

If they are running on a Windows 7 x64 machine, the path is:

C:\Windows\SysWow64\CCM\Logs\SMSTSLog\scanstate.log

The HTA then parses this log file looking for ‘MIGACTIVITY_SUCCESS’. If this message exists in the log file, the HTA returns the following box…

If it doesn’t exist, they see the following box…

Now that the HTA is functional, I have to put it in the task sequence and make it visible while running inside the full operating system. This is where the fun really begins…

Luckily, we can take advantage of ServiceUi.exe that exists in the Tools\x86 or Tools\x64 folders within the Microsoft Deployment Toolkit package. We can launch this by calling it from %toolroot%.

Placing my HTA file in a folder called CustomScripts underneath the Scripts folder in the toolkit package allows me to use the command line…

%toolroot%\serviceui.exe –process:tsprogressui.exe %systemroot%\system32\mshta.exe %scriptroot%\CustomScripts\USMTCaptureStatus.hta

Here is an example of how to call my HTA using the ServiceUi.exe…

For more information on the use of ServiceUI.exe, see ‘Can I use ServiceUI.exe to launch other programs besides the UDI Setup Wizard?’ on Cameron’s Blog – Cravings of System Center.

USMTCaptureStatus.hta

<html>
< head>
< title>USMT Capture Status</title>
< HTA:APPLICATION
APPLICATIONNAME="USMT Capture Status"
ID="USMTCaptureStatus"
SCROLL="no"/>
< /head>

' *****************
' * Window_OnLoad *
' *****************

Sub Window_OnLoad
'This method will be called when the application loads
   window.resizeTo 600,300
   window.moveto 1,1
   USMTStatus
End Sub

' *****************
' * USMTStatus *
' *****************

Sub USMTStatus
Const ForReading = 1

' Set the search parameter
Set objRegEx = CreateObject("VBScript.RegExp")
objRegEx.Pattern = "MIGACTIVITY_SUCCESS"

' Prepare log file connectivity
Set objFSO = CreateObject("Scripting.FileSystemObject")

' WMI Connectivity
strComputer = "."
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

' Query WMI for processor architecture type
Set colProcessors= objWMIService.ExecQuery ("Select * From Win32_Processor")

' Set log file location based on processor architecture type
For Each objProcessor in colProcessors
If objProcessor.Architecture = 0 Then
Set objFile = objFSO.OpenTextFile("C:\windows\system32\ccm\logs\SMSTSLog\scanstate.log", ForReading)
Else
Set objFile = objFSO.OpenTextFile("C:\windows\syswow64\ccm\logs\SMSTSLog\scanstate.log", ForReading)
End If

' Set initial returnSuccess to 'False'
returnSuccess = False

' Set HTA pop-up box text based on search results
If returnSuccess = True Then
DataArea.InnerHTML = "The user state was SUCCESSFULLY captured.<br><br>PLEASE CLOSE THIS BOX TO END THE TASK SEQUENCE."
Else
DataArea.InnerHTML = "The user state was NOT SUCCESSFULLY captured.<br><br>PLEASE CLOSE THIS BOX TO END THE TASK SEQUENCE."
End If

End Sub

< /script>

</body>
< /html>

USMTCaptureStatus.zip

This post was contributed by Brad Tucker, a Senior Consultant with Microsoft Services, East Region, United States