Intro

This blog is intended to document our learning's about Miracast technology and explain things to consider when implementing a solution using Miracast. It is primarily about Windows 8.1 tablets and Windows Phone 8.1 as the authors work for Microsoft in the Worldwide Modern Devices Centre of Excellence (CoE). We work on a program called First Wave which assists market leading customers in using and deploying the latest Windows technologies. For video case studies around our projects go to http://www.microsoft.com/en-us/windows/enterprise/customer-stories/default.aspx .

We worked on many global projects but the relevant one is the Mandarin Oriental Hotel Group , which is detailed in our second blog.

FAQ

Why do I want Miracast?

Miracast technology allows you to wirelessly project your computer/tablet or phone screen onto an HDMI connected device such as a TV or projector. You can play movies for all the family to enjoy or simply enjoy a shared web browsing experience without the need for messy cables. It is similar in concept to Apple’s AirPlay

What is Miracast?

Windows and Windows Phone 8.1 added support for Miracast projection from most devices and can either use a “dongle” that plugs into your TV or nowadays some TVs come with Miracast built in. Often the dongle is USB powered so can plug into a spare USB port on your TV. Most of the dongles are about the size of a pack of cards but some low cost USB-stick-sized devices are starting to emerge.

Plug your dongle into the TV and select the correct AV port on the TV and you will see a “Device ready for pairing” type message on the TV. On Windows 8.1 select Devices/Project from the Charms Bar and click on “Add a wireless display”. The computer will scan for devices in range and allow you to select one and go through the pairing process which may involve typing a PIN that is displayed on the TV screen. This is all rather similar to pairing a Bluetooth mouse or headset (but doesn’t actually involve Bluetooth).

On the phone, go to Settings/”Project My Screen” and a similar scanning/pairing process will be initiated. Once you have paired the device, it is persistent and you will not need to re-pair the device unless you pair the dongle with another device – you will simply be able to connect and display. You can pair with as many devices as you like and can unpair the device from Control Panel or Settings.

Note that once you log off or reboot your device, the mirrored connection is broken and cannot be re-established automatically. There are currently no public APIs to control Miracast projection.

What is performance like?

Performance varies with many factors – dongle manufacturer, computer CPU power, Wi-Fi traffic, Wi-Fi waveband etc (more details later) but you should be able to stream an HD movie from the Internet and project it to your TV with minimal stuttering. Note Miracast also transmits your sound channel as well as the picture.

What components are used in Miracast?

Miracast support is embedded into the display drivers, Wi-Fi drivers and device firmware (including dongle firmware) and it is quite sensitive to driver versions and revisions. The Miracast standard is constantly being tweaked and although backwards compatibility is promised, it is not always transparent. Each large Windows or phone update has required an update to the various components which may be on different delivery schedules. For example, getting a firmware update to the Miracast support in a TV is often a lengthy process and for this reason we recommend using a dongle rather than relying on the TV support. ActionTec have proved very responsive to requests and are tightly integrated into the Windows Operating System team (OSG) so they are the partner of choice for our team.

If you are experiencing problems, make sure you have all the latest drivers and hardware/dongle firmware installed.

What technology does Miracast use?

Miracast is an evolution of Intel’s proprietary Wireless Display (WiDi) technology and uses the Wi-Fi Direct protocol and therefore communicates directly between device and dongle without going through a Wireless Access Point or router. However, the first stage of establishing a Miracast connection senses if the computer Wi-Fi adaptor is already using a Wi-Fi connection with a router and uses the assigned channel for the Miracast communication to prevent thrashing in the Wi-Fi adaptor.

We have not seen dongles that allow the Wi-Fi channel to be manually configured so if the computer is moved and switches channel for signal strength reasons, the Miracast session may become choppy or even disconnect as it tries to switch Wi-Fi channel. Since the bandwidth requirement for transmitting HD video is very high, having more than 3 or 4 dongles sharing the same channel will probably see saturation. Also remember that if you are streaming video wirelessly from the internet, that the stream will be transmitted twice over the Wi-Fi network, one to the computer and once to the dongle. Google’s Chromecast differs in this respect as it can stream directly from the internet but only for certain applications.

What methods are available for pairing a device?

We have seen several methods of pairing the device:

Random Pin. Dongle displays a random PIN during the pairing process which must be manually typed into the computer to pair. This prevents pairing with a device that you cannot see, for example a TV in an adjacent hotel room.

Automatic pairing. Introduced on Windows in 8.1 Update 1 as the default, a device can automatically pair when you select it. Disabling this feature is sometimes desirable (eg hotel) but has to be done in the dongle firmware if it supports it but not from Windows.

Fixed secret PIN. Some dongles support manually setting a secret PIN in the dongle firmware. This prevents the device from being ad-hoc paired to other devices (eg a hotel guest using his phone) and affords greater control. When pairing you will need to know what PIN has been set or you will be unable to use the device.

Different vendors implement various methods of performing management tasks for the dongle such as upgrading the firmware or changing settings such as device name or timeouts. Some use a local USB port where you load the firmware then press a button on the device to flash it, other use mini web servers on the device (like a router) and present an HTML interface so that they can be managed remotely. Some flavors of the ActionTec firmware use a custom SSID that you connect to in order to manage the device which is a problem if you have a lot of devices as they pollute the experience when trying to connect a laptop to a Wi-Fi network for example, as all the dongle admin SSIDs are visible. You may be able to set the admin SSID to hidden.

Do all Windows 8.1 and Windows Phone 8.1 devices support Miracast?

No. This requires both hardware (Wi-Fi adaptor) and device firmware support. We have tested the following list of devices successfully: Surface Pro 1, Surface Pro 2, Surface Pro 3, Dell Venue 8 Pro, HP ElitePad, Nokia 630, 1020, 1520. Note these may require a firmware upgrade to add this support depending on the age of the device. The following devices do not support Miracast: original Surface RT.

Android 4.2 (JellyBean) or better (eg KitKat) is needed for Miracast support. Apple devices do not support Miracast as they use AirPlay which is a competing proprietary solution (implemented on Apple TV).

Do all TVs and projectors support Miracast?

You almost always require an HDMI input on the TV, so devices that do not have HDMI can be eliminated. Most Miracast solutions use 1080p for their screen resolution, but many HD TVs only support 1080i or 720p. 720p is not really sufficient for Windows 8 as it is below the minimum resolution for Modern Apps so you can’t start a Modern app when running at that resolution. Some of the dongles (eg ActionTec) however, do support 1080i and the results can be very good. (P=Progressive, I=Interlaced, Progressive shows every line, Interlaced draws every other line then goes back and fills in the alternate lines). Picture quality is generally better on 1080p. Resolutions higher than 1080p (1920x1080) are not currently supported by Miracast so 4K for example is not supported.

We tested various dongles (Netgear, ActionTec, Belkin) and TVs with embedded Miracast support (Samsung, Philips, Sony) and arrived at the conclusion that the ActionTec dongle was the most flexible in terms of environment/features and gave the best performance. Also the engineering team were very responsive and turned around custom firmware versions in a few days. For this reason our team would recommend the ActionTec dongle.

Can I add a button to the Windows 8.1 Start Screen to project the screen to aid discovery?

There are no public APIs to control Miracast projection but attached is a sample app that you can pin to the start screen that sends keystrokes to invoke the screen selection menu. The same menu is used for connection or disconnection so the app does not need any knowledge of whether the device is currently projecting or not.

The projection stutters or drops. How can I improve performance?

In a single device setting, make sure you have all the latest drivers and firmware releases including dongle firmware. If these still cause issues, you can experiment with older versions of the drivers as sometimes this helps.

If you can set up a 5GHz Wi-Fi network rather than 2.4GHz (the default) and get your computers to use that by default, this will generally give better results. 5GHz has higher bandwidth but shorter range so your mileage may vary.

In a multi-device setting (e.g. hotel) network traffic may be an issue if multiple devices are using the same channel or if the network has a lot of traffic. Most Wi-Fi Access Points (AP) can be configured to prefer a certain channel, spacing these out across your environment in a matrix arrangement can considerably improve overall Wi-Fi performance. Using a signal strength meter to obtain hard data on signal strength is very important here. There are some signal strength apps available on smart phones if you don’t have a specialized device. Again using 5GHz can be advantageous although 2.4GHz networks can still provide good results if properly configured. Remember that although the Miracast communication uses Wi-Fi Direct and does not go via your router, the channel it uses is determined by the Wi-Fi channel being used by the computer and your connection may not automatically upgrade and switch if a better channel is available. Note you may need to update your Access Point firmware in order to set up a 5GHz network or control channel separation.

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.

This blog is intended to document our learning's about Miracast technology and explain things to consider when implementing a solution using Miracast. It is primarily about Windows 8.1 tablets and Windows Phone 8.1 as the authors work for Microsoft in the Worldwide Modern Devices Centre of Excellence (CoE). We work on a program called First Wave which assists market leading customers in using and deploying the latest Windows technologies. For video case studies around our projects go to http://www.microsoft.com/en-us/windows/enterprise/customer-stories/default.aspx

The authors, Lutz Seidemann (Infra) and Paul Tallett (App Dev), worked on many of these projects but the relevant one is the Mandarin Oriental Hotel Group project which is detailed in the Customer Scenarios section. Both are Solution Architects with Microsoft Consulting Services – Worldwide Modern Device Center of Excellence.

What is Miracast

What is Miracast and how you can use it in your architectural concepts? Let's have a first look to Wikipedia:

"Miracast is a peer-to-peer wireless screencasting standard formed via Wi-Fi Direct connections in a manner similar to Bluetooth. It enables wireless delivery of audio and video to or from desktops, tablets, mobile phones, and other devices. It allows users to, for example, echo display from a phone or tablet onto a TV, share a laptop screen with the conference room projector in real-time, and watch live programs from a home cable box on a tablet. Both the sending and receiving devices must support Miracast for the technology to work. However, to stream music and movies to a device, such as a TV, that does not support Miracast, adapters are available that plug into HDMI or USB ports. Miracast allows a portable device or computer to send, securely, up to 1080p HD video and 5.1 surround sound (AAC and AC3 are optional codecs, mandated codec is linear pulse-code modulation — 16 bits 48 kHz 2 channels).The protocol uses a direct Wi-Fi connection between the two devices without involvement of a wireless router and cannot be used to stream to a router access point. It was created by the Wi-Fi Alliance." (From <http://en.wikipedia.org/wiki/Miracast> )

Ok, here the same again in a nutshell: Miracast is a protocol that will transmit audio and video between devices via Wi-Fi. It relies on the Wi-Fi network available (802.11n), using 2.4GHz and 5GHz bands. With this, you can enjoy multimedia content streaming from any Miracast enabled device such as your Windows 8.1 Tablet or Windows Phone to the Miracast device in our environment. It is not necessary that both devices are connected to the Internet. They only need to share the same local wireless network. The shared information is sent by the device via Wi-Fi through a Wi-Fi Direct connection to a receiver connected to the display device. The receiver then decodes the video signal and passes it to the TV display (or other display device). Miracast supports WPA2-PSK encryption, so all you share is safe.

Windows 8.1 or Android with version 4.2 and higher support Miracast natively. For Windows 7 you need to download the Intel WIDI drivers. If you familiar what Apple called Airplay, Miracast works similarly.

Miracast Devices

Broadcasting photos, videos, music and other media from your mobile device or PC to your TV need not be a laborious process, fraught with wires and extra peripherals. Miracast, and Intel's compatible cousin technology WiDi, let you beam whatever is on your device's screen right to a television, and there's a good chance that the devices you already own have this technology built in.

Nowadays, all Windows 8.1 PCs with recent Intel CPUs and Wi-Fi cards already have the hardware necessary. On the phone side windows 8.1 phones and Android 4.2 Jelly Bean or later you can use to send a Miracast signal. If you have a Miracast-capable Phone or Tablet, all you need is a receiver to attach to your home theatre. To help you choose, have a look on current Miracast receivers.

Step 1.) Select your Miracast receiver

You need make sure the Miracast device is compatible with your TV. Most Miracast solutions use 1080p for their screen resolution, but many older TVs only support 1080i or even only 720p. The only device we found that can support 1080i & 1080p is the Actiontec Screen-Beam Pro.

The Wi-Fi Alliance website maintains a comprehensive list of compatible devices, although that list does not account for Miracast-compatible technologies like Samsung's AllCast Share. More information, including a list of Wi-Fi Certified Miracast products, the Wi-Fi Alliance Display technical specification, white paper, and more is available at www.wi-fi.org/miracast.

Step 2.) Connect your Miracast receiver to your TV

All Miracast receivers plug into a TV's HDMI port and are ready to receive as soon as they turn on.

Step 3.) Connect your Windows 8.1 PC or Tablet

After you added your Miracast connection , from now you can access via the usual project

Step 3.a) Connect your Windows 8.1 Phone

Step 3.b) Connect your Android Phone

Note: instructions differ depending on whether you are streaming from an different Android version. This is Android 4.4 (KitKat)

Go to Settings/Connections and tap on Screen Mirroring

You will then see this screen and you can tap your Miracast dongle:

The device will go through the pairing process:

And your screen is now mirrored and you can tap to disconnect:

Customer Scenario

One year ago Mandarin Oriental partnered up with Microsoft in early adopter program called Windows Firstwave.

Mandarin Oriental’s intention is to make its wealth of online marketing content, hotel information and guest services more easily accessible to its digitally savvy guests. Leveraging the Microsoft platform, Mandarin Oriental is able to integrate a combination of services formerly offered via the television, telephone or guest directory with content available on the company’s website to deliver a more intuitive in-room experience for guests via custom touch apps running on Microsoft Surface Pro tablets. The Mandarin Oriental Group has piloted Microsoft Surface Pro tablets in four of their award-winning properties in London, Washington DC, Las Vegas and Tokyo.

Microsoft Consulting Services worked together with the hospitality solutions partner iRiS Software Systems, and InterKnowlogy to develop a suite of custom Windows 8.1 touch apps, available in nine different languages, that manage services for in-room dining, concierge and housekeeping requests, a guest compendium which provides information about the hotel’s facilities and access to guest feedback and guest preferences.

Here a quick overview of the solution architecture before we go deep on our Miracast implementation experiences during the pilot:

During the Architecture design session we proposed to use Windows Embedded 8.1 Industry on Microsoft Surface Pro to Mandarin Oriental. This version of Windows 8.1 is functionally identical to the consumer/pro versions of Windows 8.1 with the exception that Embedded 8.1 industry adds capabilities to lock down the device - in this specific case a Write Filter is used to write all changes that happen to the OS after it is booted into a cache which is then overlaid on the file system. In normal operation this cache is transparent to the user and Industry Embedded 8.1 operates as any Windows 8.1 PC would. However when the Surface Pro is rebooted the cache is deleted restoring the Surface Pro device to the install state. This is how user state (files, downloaded apps, browsing history, customization, etc.) is removed through a reboot initiated at checkout. It's a simple and effective process and it's similar to the way that 3rd Party products (e.g. Deep Freeze) works except in this case, the capability is built into the OS making Surface Pro with Windows Industry 8.1 ideal for this type of commercial application. The user can install any app, download email, work on documents, change any configuration they want, including log into a Microsoft Account (MSA) with the surety that at checkout, or when the Surface device is rebooted, all user-specific data is removed.

Additionally, all OS updates are applied after checkout by automatically switching the device to Servicing Mode where the write filter is disabled and all the patches applied keeping the install image secure and up to date. For real-time updates required by application such as Defender or Microsoft Forefront you can add folder level write filter exclusions to prevent that data being wiped off at reboot. An important benefit of this approach is that specific hotel apps can be sourced from multiple developers, and these can be complemented by any app that can be downloaded from the Windows Store (the very functional Bing apps for example).

This contrasts with the alternative Android/iOS mechanisms in use for tablets deployed for this type of application in hotels. For these OS's which do not have such evolved management mechanisms, the typical approach is to build one large app that must contain all required functionality. The tablet is then locked in kiosk mode running this app only. Writing one big monolithic app is clearly a less efficient software development approach, and it removes from the user experience nearly all of the familiar tablet functionality associated with the OS - i.e. something as simple as a web browser - if such functionality is desirable to include in the user experience, must be written/included in the hotel app development process. In Windows 8.1 Industry Embedded such functionality, and much more, is included out of the box leaving the developers to spend their time and money developing line-of-business hotel-specific functionality which means they can be potentially much more productive. (Read the Mandarin Oriental Hotel Group Press Release , Blog or watch the Video )

OK, let's circle back to Miracast, what this blog is all about :

Part of the Mandarin Solution is Miracast to provide all guests the possibility to stream there preferred videos, watch Hulu or Netflix, internet TV channels or any other content direct on the big in-room TV. Imagine you go into a hotel room and can watch your preferred movie without messing around with a cable connection or different kinds of adapters. You just connect to Netflix and watch, I would call this very slick.

What you need consider to build such a solution?

Remember that although the Miracast communication uses Wi-Fi Direct and does not go via your router, the channel it uses is determined by the Wi-Fi channel being used by the computer and your connection may not automatically upgrade and switch if a better channel is available. In a multi-device setting network traffic may be an issue if multiple devices are using the same channel or if the network has a lot of traffic. That’s important for environments such as Hotels, where you have many Miracast devices (Dongle and PC/Phone) very close to each other.

Understand your Wi-Fi Network:

Most Wi-Fi Access Points (AP) can be configured to prefer a certain channel, spacing these out across your environment in a matrix arrangement can considerably improve overall Wi-Fi performance. Using a signal strength meter to obtain hard data on signal strength is very important here. There are some signal strength apps available on smart phones if you don’t have a specialized device.

In general the 5GHz bandwidth is less noisy than 2.4GHz ; you can find baby monitors, microwave or Bluetooth devices sending on 2.4GHz. More information here.

If you can set up a 5GHz Wi-Fi network rather than 2.4GHz (the default) and get your computers to use that by default, this will generally give better results. 5GHz has higher bandwidth but shorter range so your mileage may vary. Configure your Router for "Optimize for compatibility" mode, which allow to configure a separated 5GHz channel per room (36,40,44,48,149,153,157,161).

Drivers and Firmware

Make sure you have all the latest Wi-Fi drivers and device firmware releases

Code samples

For the Mandarin Oriental project we wrote a Modern app that sent keystrokes to invoke the charms bar and bring up the projection screen which we pinned to the Start Screen to make it very easy for guests to discover this functionality. Since Modern apps are not allowed to send keystrokes to the system, we used a technique called Brokered Components which allows desktop code to be called from a side-loaded Modern app. Sending the keystrokes is fairly trivial, here's the code we used in the Brokered Component:

Summary

As a recap, Miracast is a very exciting technology and if you spend a little time on the key points it works very well. After testing a few dongles, we selected ActionTec because of the wider selection of TV resolution (1080i and 1080p) and configuration options we got in the firmware. Working with the Actiontec engineering team was a pleasure. Your environment may differ, so we don’t want to give a generic recommendation.

Those are the critical components :

WI-FI Drivers

Tablet Firmware

Wi-Fi Router Firmware

Wi-Fi Network configuration

Miracast Dongle

Dongle Firmware

Finally, give us feedback; share your implementation experiences; ask question and we will try to help.

Happy Implementing Lutz and Paul

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 theTerms of Use.

Although you won’t find it mentioned in the MDT documentation, in an OSD task sequence the MDT Gather step will attempt to set a variable called SMSDP to the distribution point server name from which the boot image was obtained. This can be handy if you want to do something like copy the logs to a “local” DP.

MDT does this in the GetDP function in the script ZTIGather.wsf. It uses the following logic:

Get the boot image ID by looking at the value of the _SMSTSBootImageID variable, e.g. PRI00001.

Use that value to form the name of the variable to retrieve, _SMSTS%_SMSTSBootImageID%, e.g. _SMSTSPRI00001, then retrieve the value of that variable.

Split that variable on all “,” values, then pick the first non-SMSPXEIMAGES$ path.

Parse the string to get just the server name.

Unfortunately, this method that MDT uses to determine the “local” DP name has some issues. First, if you do not have a boot image associated with the task sequence then SMSDP will never have a value. Second, during a refresh task sequence the _SMSTS%_SMSTSBootImageID% variable will not have any value until the content is requested and downloaded. So from the beginning of the task sequence until the reboot into WinPE, SMSDP will never have a value.

To get around these limitations I created a function that uses the following logic:

Load task sequence XML from the _SMSTSTaskSequence variable.

Find the package IDs for the referenced packages.

For each package query the _SMST<package ID>, _SMSTSMB<package ID>, and the _SMSTHTTP<package ID> variables in turn.

If a value is found it will split that variable on all “,” values, then pick the first non-SMSPXEIMAGES$ path.

Parse the string to get just the server name.

So with this logic, as long as any package has been requested and download SMSDP should get a value. Since the Use Toolkit Step runs very early, this code only has to run after that step to be successful. I created a function called GetSMSDP and placed it in the HelperFunctions class of the library script that I have been building up over the years called MDTLibHelperClasses.vbs.

I have provided two methods of using this function. The first is to call it directly from CustomSettings.ini using MDTLibHelperClasses.vbs as a User Exit script during the Gather step. Place MDTLibHelperClasses.vbs in the MDT Toolkit package Scripts folder. You will also need to place a MDTExitInclude.vbs from a previous post in the MDT Toolkit package Scripts folder. Make the following additions to CustomSetting.ini in the MDT Settings package:

The second method is to run this as a script in a Run Command Line step. Place MDTSetSMSDP.wsf and MDTLibHelperClasses.vbs in the MDT Toolkit package Scripts folder. Then create a Run Command Line step shortly after the first Gather step with the following command line:

cscript "%DeployRoot%\Scripts\MDTSetSMSDP.wsf"

Both MDTSetSMSDP.wsf and version 2.1.4 of MDTLibHelperClasses.vbs (the latest as of this writing) can be found in the attached Zip file.

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.

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

While writing my last entry titled Pre-Flight Checks – Wireless Connectivity, I figured I would go ahead and post this script that does a pre-flight check to check the S.M.A.R.T. status of the hard drive. S.M.A.R.T. stands for Self_Monitoring Analysis & Reporting Technology and it allows the machine to effectively predict impending failures of the hard drive.

To check this status of the hard drive, I am looking at the Win32_DiskDrive class. This class has an object called Status that keeps track of, oddly enough, the status of the hard drive. The status we are looking for is ‘OK’. For more information on the Win32_DiskDrive class, or Status, click here.

As always, I am using the zero touch script format in a custom .wsf file. For more information on custom ZTI scripts, please visit here.

To add this check to the task sequence, I have added it into a command-line task utilizing the shown syntax.

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

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

While writing my last entry titled Pre-Flight Checks – Wireless Connectivity, I figured I would go ahead and post this script that does a pre-flight check to ensure the machine is plugged in to AC power. With the numbers of mobile devices becoming more and more prevalent in today’s enterprises, a check to ensure the device is plugged in prior to beginning imaging is crucial.

As I stated in my prior post (see above), MDT offers some checks, and even offers a wireless and AC power check within the UDI wizard. These last two checks, however, would require a touch for the wizard, as they are built in. Thus, this simple script to check the mobile device for AC power.

To check if the device is plugged in, I am looking at the Win32_Battery class. This class has an object called BatteryStatus that keeps track of, oddly enough, the status of the battery. The status we are looking for is ‘2’. This is recognized as ‘The system has access to AC so no battery is being discharged. However, the battery is not necessarily charging’. For more information on the Win32_Battery class, or BatteryStatus, click here.

When adding this check to the task sequence, I add it to a standard command-line step and set it to run only if ISDESKTOP = ‘FALSE’ and ISSERVER = ‘FALSE’.

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

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

As many of you know, MDT offers a series of ‘pre-flight’ checks you can run at the beginning of a task sequence to verify any number of things – BitLocker state, memory, Windows Scripting Host, etc… They exist within the Tools\x64\Preflight and Tools\x86\Preflight folders located in the deployment share. Within the UDI Wizard, there are even checks to ensure the machine is plugged into AC power and to ensure the machine is using a wired LAN connection and not wireless. These checks are part of the compiled code and not available to us via a script. This is fine for Lite Touch Installation, but since it requires a touch, it would not work for a Zero Touch deployment.

I have been recently asked to create a wireless check to insert into the task sequence. I built it with the following requirements…

It must check to see if the currently used network connection was a wireless connection

If it determines the current connection to be wireless, it must return an error, or non-zero code

It must log with the rest of the OSD logs.

Determine the Current Adapter

First we have to determine the currently used adapter. To do this, I looked in the Win32_NetworkAdapterConfiguration class. I queried for anything with IPEnabled = TRUE and then verified it had a valid IP address.. While this seemed to pull all active adapters, the script continued to tell me the machine was connected via LAN, even though it was on wireless. The problem was related to the Hyper-V adapters I had installed. The Hyper-V virtual adapters were seen by the computer as a physical adapter and an additional ‘Local Area Connection’. Thus, the script assumed a physical adapter was in use.

To get around this, I modified the WMI query to look like this:

SELECT * FROM win32_NetworkAdapterconfiguration WHERE IPEnabled = TRUE AND NOT Caption LIKE '%Hyper-V%'

Now that we have the currently used adapter, we need to know if it is wireless. The approach I chose to take is to query the registry. The key we are looking for is HKLM\SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}. Now we can look through each of the machine’s connections in the sub keys. As we loop though them, we are looking for a connection with a MediaSubType = 2. This type is returned for all adapters classified NdisPhysicalMediumWirelessLan in OID_GEN_PHYSICAL_MEDIUM. More information on this OID can be found here. Once we find this adapter, we retrieve its name.

NOTE: In some rare cases, a wireless adapter may show a MediaSubType other than 2. These are usually due to the adapter not supporting the wireless configuration service or the vendor uses a proprietary tool. Please contact the vendor for assistance.

Getting Results

Now that we have the wireless adapter name from the registry (sRegWlanName) and the name of the currently used adapter (sAdapterName), we compare the two. If they equal each other, then wireless status is set to TRUE and we return a non-zero code (1).

This takes care of the first two requirements, but to cover the third I am using a .WSF script template. For more information on the ZTI scripting template, click here.

We now have determined what type of connection the machine is using, but we need to do one more thing before it can be implemented. We need to make sure that all connections that show as LAN connected are not, in fact, VPN connections. To do this, I am searching the adapter name for anything identified in my array sVPNAdapters.

'// VPN adapter strings
sVPNAdapters = Array("VPN","JUNIPER")

I am only looking for “VPN” or “Juniper”, but you can easily add to this for different VPN types.

Now that we have what to look for, we need to compare it to the adapter name previously recorded. As you can see, if it finds “VPN” or “JUNIPER”, it sets IsVPNAdapter = TRUE and returns a non-zero code.

Now that I have a functional script, I am going to add it to the task sequence. I have named the script z-WirelessCheck.wsf and have placed it in the Scripts folder within my Microsoft Deployment Toolkit package. So to add it to the task sequence, I have simply created a command-line task and used the following syntax – cscript.exe "%deployroot%\scripts\z-WirelessCheck.wsf" /debug:true

NOTE: Make sure that “Continue on error” is not checked in the Options tab.

I want to give credit to Veeraswamy ”Swamy” Achanta for contributing to this script.

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

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

Microsoft Customer Services & Support (CSS) with assistance from the PowerShell team and the Garage has released some very cool scripting tools. Since those of us involved with deployments are always creating/modifying/sharing scripts, these tools look to be right up our alley. These tool are:

Script Browser – IT Pros can search, download and manage 9000+ TechNet automation script samples covering almost all Microsoft IT products from within their scripting environment. Script Browser even supports offline search so users can download all interesting scripts and search them when they do not have internet access.

The teams developing these tools are committed to continuously adding new features and benefiting IT Pros’ work. They have an ambitious roadmap. If you love what you see in Script Browser & Script Analyzer, please recommend it to your friends and colleagues. If you encounter any problems or have any suggestions, please contact onescript@microsoft.com. Your opinions and comments are more than welcome.

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.

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

Update 2014-04-16: I forgot to include that fact that a locationModify rule is required when using the %HklmWowSoftware% variable. The post has been updated to reflect this.

One challenge with capturing the settings for a 32-bit applications with USMT is that some file and Registry paths will be different on 32-bit operating systems and 64-bit operating systems. On a 32-bit operating system 32-bit programs typically get installed to C:\Program Files and local machine Registry entries are written to a subkey of HKLM\Software. However, on a 64-bit operating system , 32-bit programs get installed to C:\Program Files (x86) and HKLM\Software Registry entries are redirected to HKLM\SOFTWARE\Wow6432Node. (I have oversimplified this here for brevity's sake. See this section of the Programming Guide for 64-bit Windows for more details: http://msdn.microsoft.com/en-us/library/aa384249(v=vs.85).aspx.)

Because of this, you might think you would need to different components to migrate 32-bit application settings depending on the source and destination operating system architecture. For example, I had a customer that was using three different XML files with components for 32-bit applications. I’ll illustrate this using a fictitious 32-bit application called MyApp. This application is installed by default to C:\Program Files\MyApp and creates machine-based settings in HKLM\Software\MyApp on a 32-bit OS. For the sake of simplicity for this example, lets say that the desired way to migrate this app is to capture all the files in the C:\Program Files\MyApp\Config folder and to capture all of HKLM\Software\MyApp (or the equivalent locations on a 64-bit OS).

The customer had three different migration scenarios:

Windows XP 32-bit to Windows XP 32-bit (break/fix rebuilds, etc.)

Windows XP 32-bit to Windows 7 64-bit (OS migration)

Windows 7 64-bit to Windows 7 64-bit (break/fix rebuilds, etc.)

For Windows XP 32-bit to Windows XP 32-bit migrations they had a component like this for MyApp.

For Windows XP 32-bit to Windows 7 64-bit migrations they had a component like this for MyApp. This has locationModify rules to move the migrated items to the redirected locations for 32-bit apps on 64-bit Windows.

Of course, this makes it complicated to call USMT with the correct XML file depending on what source and destination operating systems were involved. Fortunately, there is a way to avoid this. It involves using a technique I lifted directly from MigApp.xml. MigApp.xml contains a namedElements node that defines a bunch of global items. Some of these items define single variables representing the file and local machine Registry locations for 32-bit applications independent of the operating system architecture. You can copy this into your own custom XML files and use those variables in the same way. Copy the XML content below into your custom XML files (just after the migration node at the top)

The variable %ProgramFiles32bit% will resolve correctly to C:\Program Files on a 32-bit OS and C:\Program Files (x86) on a 64-bit OS. The variable %HklmWowSoftware% will resolve correctly to HKLM\Software on a 32-bit OS and HKLM\SOFTWARE\Wow6432Node on a 64-bit OS.

Note that you need to add four environment nodes shown in the above example into your components that will use these variables. This is essentially adding a “reference” to the namedElements items that define the variables.

You also need a locationModify rule like the one show above when using the %HklmWowSoftware% variable. It may seem odd to need a location modify that has the same source and destination location. However, this is needed because USMT does not automatically redirect Registry locations. It will try to write them back to the original location. Fortunately, the locationModify RelativeMove function will expand the environment variables of the first parameter in the context of the source machine and the second parameter in the context of the destination machine. This will cause the Registry entries to be redirected properly.

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.

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

Last year I published a PowerShell script that is designed to remove the built-in Windows 8 applications when creating a Windows 8 image. Well now that Windows 8.1 has been released we must update the PowerShell script to work with Windows 8.1.

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. The script is designed to work as part of an MDT or Configuration Manager task sequence. If it detects that you are running the script within a task sequence it will log the to the task sequence folder otherwise it will log to the Windows\temp folder.

This post was contributed by Ben Hunter, a Senior Product Marketing Manager with Microsoft

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.

Last year I published a PowerShell script that is designed to remove the built-in Windows 8 applications when creating a Windows 8 image. Well now that Windows 8.1 has been released we must update the PowerShell script to work with Windows 8.1.

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. The script is designed to work as part of an MDT or Configuration Manager task sequence. If it detects that you are running the script within a task sequence it will log the to the task sequence folder otherwise it will log to the Windows\temp folder.

This post was contributed by Ben Hunter, a Senior Product Marketing Manager with Microsoft

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.

The OSVersion variable is populated with a short string representing the version of the operating system (e.g. XP, Vista, Win7Client, 2008, etc.). With MDT 2012, you may have noticed that when you deploy Window 8 that the value of the OSVersion variable gets set to “Other” instead of something like “Win8”. This is because the MDT team has deprecated the OSVersion property. The logic that set this property has not been updated for Windows 8 and will no longer be updated. The team decided that using these string values in script logic leads to hidden bugs and unexpected behavior as new OS versions are released. For example, code testing for a client OS that is Windows Vista or higher would require something like this using OSVersion:

This would work until Windows 8 was released. Then this would have to be updated with another OR with the Windows 8 value. They now recommend using a variable called OSCurrentVersion which has a value of the OS major and minor version (e.g. 6.1 for Windows 7). So the equivalent code using OSCurrentVersion would look like this and would continue to work as new operating systems are released:

While I wholeheartedly agree with this reasoning, there is one instance where I like an easily recognized string for the OS version. This is composite custom property called ModelOSArchAlias that I defined in my Model Alias post. which combines the ModelAlias, OSVersion, and Architecture properties. These values are used to create Make and Model entries in the MDT database. Using OSCurrentVersion instead of OSVersion would lead to ModelOSArchAlias values like ThinkPadT420_6.1_X64 instead of the more easily readable ThinkPadT420_Win7Client_X64. Also, since Windows team seems to have developed an aversion to increasing the major version of Windows, I see it becoming easy to confuse which version you are referencing with an OSCurrentVersion of 6.0, 6.1, 6.2, or 6.3 (Windows Vista, 7, 8, and 8.1 respectively).

So to make it possible to use a short string representing the version of the operating system that is current, I’ve created a function called GetOSVersionTag that is essentially a copy of the ZTIGather.wsf code that sets OSVersion with some improvements and updated to set proper values for Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2. I have placed this function in a class library script that I have been building up over the years called MDTLibHelperClasses.vbs. This script is conceptually similar to ZTIUtility.vbs. It can be referenced similarly in other MDT scripts and using the technique from my last post it can also be used as a User Exit script. As I create new general purpose functions going forward, I will place them in future versions of this library as appropriate.

To use this function to create a custom variable called OSVersionTag and use that in ModelOSArchAlias, add MDTLibHelperClasses.vbs (and MDTExitInclude.vbs and ModelAliasExit.vbs from the two previous posts referenced earlier) to the Scripts folder of your Deployment Share or Configuration Manager MDT Files package and add the following to CustomSetting.ini (used during Gather in the newly deployed OS):

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.

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

The OSVersion variable is populated with a short string representing the version of the operating system (e.g. XP, Vista, Win7Client, 2008, etc.). With MDT 2012, you may have noticed that when you deploy Window 8 that the value of the OSVersion variable gets set to “Other” instead of something like “Win8”. This is because the MDT team has deprecated the OSVersion property. The logic that set this property has not been updated for Windows 8 and will no longer be updated. The team decided that using these string values in script logic leads to hidden bugs and unexpected behavior as new OS versions are released. For example, code testing for a client OS that is Windows Vista or higher would require something like this using OSVersion:

This would work until Windows 8 was released. Then this would have to be updated with another OR with the Windows 8 value. They now recommend using a variable called OSCurrentVersion which has a value of the OS major and minor version (e.g. 6.1 for Windows 7). So the equivalent code using OSCurrentVersion would look like this and would continue to work as new operating systems are released:

While I wholeheartedly agree with this reasoning, there is one instance where I like an easily recognized string for the OS version. This is composite custom property called ModelOSArchAlias that I defined in my Model Alias post. which combines the ModelAlias, OSVersion, and Architecture properties. These values are used to create Make and Model entries in the MDT database. Using OSCurrentVersion instead of OSVersion would lead to ModelOSArchAlias values like ThinkPadT420_6.1_X64 instead of the more easily readable ThinkPadT420_Win7Client_X64. Also, since Windows team seems to have developed an aversion to increasing the major version of Windows, I see it becoming easy to confuse which version you are referencing with an OSCurrentVersion of 6.0, 6.1, 6.2, or 6.3 (Windows Vista, 7, 8, and 8.1 respectively).

So to make it possible to use a short string representing the version of the operating system that is current, I’ve created a function called GetOSVersionTag that is essentially a copy of the ZTIGather.wsf code that sets OSVersion with some improvements and updated to set proper values for Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2. I have placed this function in a class library script that I have been building up over the years called MDTLibHelperClasses.vbs. This script is conceptually similar to ZTIUtility.vbs. It can be referenced similarly in other MDT scripts and using the technique from my last post it can also be used as a User Exit script. As I create new general purpose functions going forward, I will place them in future versions of this library as appropriate.

To use this function to create a custom variable called OSVersionTag and use that in ModelOSArchAlias, add MDTLibHelperClasses.vbs (and MDTExitInclude.vbs and ModelAliasExit.vbs from the two previous posts referenced earlier) to the Scripts folder of your Deployment Share or Configuration Manager MDT Files package and add the following to CustomSetting.ini (used during Gather in the newly deployed OS):

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.

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

Most readers of this blog should be familiar with MDT User Exit scripts, as many of the posts provided them for many scenarios. In case you are not, the MDT help file defines them this way:

“A user exit script is effectively a function library that can be called during the processing of the CustomSettings.ini file using the UserExit directive. A user exit script contains one or more functions that can be called during the process of the CustomSettings.ini file.”

User exit scripts are a great way to extend the Gather process. However, how ZTIGather.wsf actually process user exit scripts has implications for which scripts you can use as user exit scripts.

When ZTIGather.wsf finds a UserExit entry in a CustomSettings.ini section, it actually processes the user exit script twice, once at the beginning of the section processing and once at the end. When it does this it first loads the contents of the user exit script file into a string variable, executes the loaded code in the global namespace of a script using the VBScript ExecuteGlobal statement, and then calls the UserExit function that is included in the script.

The UserExit function I usually include is similar to this and requires the function signature (set of parameters) shown below:

The sType input parameter is always called with a value of "SECTION". The sWhen input parameter is called with "BEFORE" at the beginning of section processing and "AFTER" at the end of section processing. The sDetail input parameter is the CustomSettings.ini section name. The bSkip parameter is a return parameter. If bSkip is set to True in the UserExit function when it is called at the beginning of section processing, the rest of that section in CustomSettings.ini is skipped.

This behavior allows you to run different code at the beginning or end of section processing or skip section processing based on code run at the beginning of section processing like the trivial samples shown below.

While this functionality is interesting, I have never had any occasion where I needed to use it. I only know one person who has put logic in a UserExit function, fellow Deployment Guy Dave Hornbaker. So why did I bother explaining it to you? Well, as I said earlier it has implications for which scripts you can use as user exit scripts.

The first is that any script you want to use as a user exit script must have a UserExit function. Fellow Deployment Guy Dave Hornbaker once needed to use ZTIDiskUtility.vbs functions in one of his user exit scripts. Now he could have either added a UserExit function to ZTIDiskUtility.vbs so it could be used as a user exit script directly as well or added a script tag to ZTIGather.wsf that referenced ZTIDiskUtility.vbs. However, we generally recommend against modifying the scripts that ship with MDT unless it is absolutely necessary. If you do, then you have to remember to redo those changes when applying an update to MDT.

The second is that the when a user exit script contains VBScript Classes, the second ExecuteGlobal of the contents at the end of section processing fails with a “name redefined” error. This causes ZTIGather.wsf execution to fail.

To overcome both of these limitations, I created a user exit script (MDTExitInclude.vbs) with a function called Include that only loads the contents of a VBScript file into a string variable, executes the loaded code using the VBScript ExecuteGlobal statement, and only does this once. So while this does not allow the little-used section processing control behavior I described above, this function essentially allows you to use any VBScript as a user exit script.

After adding MDTExitInclude.vbs to Scripts folder in the LTI Deployment Share or ConfigMgr MDT Toolkit package, modify CustomSetting.ini similar to the example below to load MDTExitInclude.vbs as a user exit script and then load another script using the Include function. This sample loads a script named TestUserExit.vbs and make functions inside it available for use.

One other advantage of loading user exit scripts in this fashion is that it simplifies loading multiple scripts. For example, I recently needed to load five user exit scripts for one deployment. Normally this would require creating five sections in CustomSettings.ini since you can only have one UserExit directive per section. Using MDTExitInclude.vbs you can load as many scripts as you want in a single section like this:

This sample uses one “throw away” list item, ExitScripts, to execute the Include function for each script. This avoids “Settings section bloat” by not requiring multiple entries in the Priority or Properties line for just loading multiple scripts.

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.

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

Most readers of this blog should be familiar with MDT User Exit scripts, as many of the posts provided them for many scenarios. In case you are not, the MDT help file defines them this way:

“A user exit script is effectively a function library that can be called during the processing of the CustomSettings.ini file using the UserExit directive. A user exit script contains one or more functions that can be called during the process of the CustomSettings.ini file.”

User exit scripts are a great way to extend the Gather process. However, how ZTIGather.wsf actually process user exit scripts has implications for which scripts you can use as user exit scripts.

When ZTIGather.wsf finds a UserExit entry in a CustomSettings.ini section, it actually processes the user exit script twice, once at the beginning of the section processing and once at the end. When it does this it first loads the contents of the user exit script file into a string variable, executes the loaded code in the global namespace of a script using the VBScript ExecuteGlobal statement, and then calls the UserExit function that is included in the script.

The UserExit function I usually include is similar to this and requires the function signature (set of parameters) shown below:

The sType input parameter is always called with a value of "SECTION". The sWhen input parameter is called with "BEFORE" at the beginning of section processing and "AFTER" at the end of section processing. The sDetail input parameter is the CustomSettings.ini section name. The bSkip parameter is a return parameter. If bSkip is set to True in the UserExit function when it is called at the beginning of section processing, the rest of that section in CustomSettings.ini is skipped.

This behavior allows you to run different code at the beginning or end of section processing or skip section processing based on code run at the beginning of section processing like the trivial samples shown below.

While this functionality is interesting, I have never had any occasion where I needed to use it. I only know one person who has put logic in a UserExit function, fellow Deployment Guy Dave Hornbaker. So why did I bother explaining it to you? Well, as I said earlier it has implications for which scripts you can use as user exit scripts.

The first is that any script you want to use as a user exit script must have a UserExit function. Fellow Deployment Guy Dave Hornbaker once needed to use ZTIDiskUtility.vbs functions in one of his user exit scripts. Now he could have either added a UserExit function to ZTIDiskUtility.vbs so it could be used as a user exit script directly as well or added a script tag to ZTIGather.wsf that referenced ZTIDiskUtility.vbs. However, we generally recommend against modifying the scripts that ship with MDT unless it is absolutely necessary. If you do, then you have to remember to redo those changes when applying an update to MDT.

The second is that the when a user exit script contains VBScript Classes, the second ExecuteGlobal of the contents at the end of section processing fails with a “name redefined” error. This causes ZTIGather.wsf execution to fail.

To overcome both of these limitations, I created a user exit script (MDTExitInclude.vbs) with a function called Include that only loads the contents of a VBScript file into a string variable, executes the loaded code using the VBScript ExecuteGlobal statement, and only does this once. So while this does not allow the little-used section processing control behavior I described above, this function essentially allows you to use any VBScript as a user exit script.

After adding MDTExitInclude.vbs to Scripts folder in the LTI Deployment Share or ConfigMgr MDT Toolkit package, modify CustomSetting.ini similar to the example below to load MDTExitInclude.vbs as a user exit script and then load another script using the Include function. This sample loads a script named TestUserExit.vbs and make functions inside it available for use.

One other advantage of loading user exit scripts in this fashion is that it simplifies loading multiple scripts. For example, I recently needed to load five user exit scripts for one deployment. Normally this would require creating five sections in CustomSettings.ini since you can only have one UserExit directive per section. Using MDTExitInclude.vbs you can load as many scripts as you want in a single section like this:

This sample uses one “throw away” list item, ExitScripts, to execute the Include function for each script. This avoids “Settings section bloat” by not requiring multiple entries in the Priority or Properties line for just loading multiple scripts.

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.

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

There are occasions where the variables I needed to use to query or retrieve data from the database were not the ones that match the field names in the database. Luckily, the MDT Gather process supports variable remapping in the database sections of CustomSetting.ini to do just that.

I demonstrated one type of variable remapping in my post on Model Aliases. I wanted to query Model settings, apps, etc. using the ModelAlias instead of the Model. Since Model is the field in the database that the queries use to find the records, we have to tell Gather that is should use the value found in the ModelAlias variable to query the Model field in the database instead.

The standard Make/Model Settings database section looks like the one below. The table (view) in the database is MakeModelSettings and the fields used to find the records are Make and Model.

For my ModelAlias Settings sections I only was interested in finding records with a matching Model field, but the value I wanted to match was actually stored in the ModelAlias variable. The changes shown in red tell Gather to do exactly that:

This tells Gather to use ModelAlias for the value of the input parameter and that this parameter is to match the Model field.

I recently needed to do the second type of variable remapping, placing the results from a field in a returned records into a variable that is different from the name of the field. In my scenario, I needed to place the results of the different application queries into different list variables. The default database sections for getting applications (CApps, LApps, MMApps, RApps) will fill the results into the Applications list variable, which matches the name of the field in the returned results. I needed each of the queries to return the results into different variables so that I could later append them back together in a certain order with results from some other steps in the task sequence in the mix. For example, say I wanted the store the results of MMApps into variable called ModelApps instead of applications.

To return the results into ModelApps, you first need to define the custom variable in the Properties line and then add the remapping line to the MMApps section (shown in red). (In case you haven’t see this, adding (*) at the end of a variable name in the Properties line tells Gather that the custom variable is a list variable.)

One unfortunate quirk of this type of remapping is that the original variable (Applications) will also be filled with the results. So you have to be aware of this if you had hoped that Applications would remain empty so it could be used else ware, as I had . I was going to use Applications as the final appended list. I had to use another custom list variable instead.

If necessary, you can also use both types of remapping in database sections at the same time.

Update 2013-08-20: I forgot to mention that this same remapping of input parameters and output variables can also be done in CustomSetting.ini Web Service query sections.

Update 2013-09-10: I recently discovered that when remapping input parameters, if the parameter is a list item then the remapped value will be added to the original list item. For example, recently I wanted to query a list of applications from a specific role name and map it to a specific output list item like this:

In this example, RoleCore is being input for the parameter Role. Since Role is a list item, the value stored in RoleCore, “Core Applications” in this example, will be added as Role001. This is another thing to keep in mind when remapping variables.

I’ll describe ways to clear out the list items that are getting filled unintentionally by remapping in another post.

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.

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

There are occasions where the variables I needed to use to query or retrieve data from the database were not the ones that match the field names in the database. Luckily, the MDT Gather process supports variable remapping in the database sections of CustomSetting.ini to do just that.

I demonstrated one type of variable remapping in my post on Model Aliases. I wanted to query Model settings, apps, etc. using the ModelAlias instead of the Model. Since Model is the field in the database that the queries use to find the records, we have to tell Gather that is should use the value found in the ModelAlias variable to query the Model field in the database instead.

The standard Make/Model Settings database section looks like the one below. The table (view) in the database is MakeModelSettings and the fields used to find the records are Make and Model.

For my ModelAlias Settings sections I only was interested in finding records with a matching Model field, but the value I wanted to match was actually stored in the ModelAlias variable. The changes shown in red tell Gather to do exactly that:

This tells Gather to use ModelAlias for the value of the input parameter and that this parameter is to match the Model field.

I recently needed to do the second type of variable remapping, placing the results from a field in a returned records into a variable that is different from the name of the field. In my scenario, I needed to place the results of the different application queries into different list variables. The default database sections for getting applications (CApps, LApps, MMApps, RApps) will fill the results into the Applications list variable, which matches the name of the field in the returned results. I needed each of the queries to return the results into different variables so that I could later append them back together in a certain order with results from some other steps in the task sequence in the mix. For example, say I wanted the store the results of MMApps into variable called ModelApps instead of applications.

To return the results into ModelApps, you first need to define the custom variable in the Properties line and then add the remapping line to the MMApps section (shown in red). (In case you haven’t see this, adding (*) at the end of a variable name in the Properties line tells Gather that the custom variable is a list variable.)

One unfortunate quirk of this type of remapping is that the original variable (Applications) will also be filled with the results. So you have to be aware of this if you had hoped that Applications would remain empty so it could be used else ware, as I had . I was going to use Applications as the final appended list. I had to use another custom list variable instead.

If necessary, you can also use both types of remapping in database sections at the same time.

Update 2013-08-20: I forgot to mention that this same remapping of input parameters and output variables can also be done in CustomSetting.ini Web Service query sections.

Update 2013-09-10: I recently discovered that when remapping input parameters, if the parameter is a list item then the remapped value will be added to the original list item. For example, recently I wanted to query a list of applications from a specific role name and map it to a specific output list item like this:

In this example, RoleCore is being input for the parameter Role. Since Role is a list item, the value stored in RoleCore, “Core Applications” in this example, will be added as Role001. This is another thing to keep in mind when remapping variables.

I’ll describe ways to clear out the list items that are getting filled unintentionally by remapping in another post.

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.

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

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

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.

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.

▪ 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

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.

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.

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

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.

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.

▪ 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

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.

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.

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

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.

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

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.

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

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.

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

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.