Exploring the Chocolatey Package Manager for Windows

Note: An edited version of this article appeared on Computerworld.com on November 13, 2018.

I’ve administered both Windows and Linux systems for close to two decades now, and honestly while Linux is a fantastic operating system and very appropriate in many respects for many applications, I’ve long preferred Windows for its generally better ease of use and polish. But that doesn’t mean Linux hasn’t had features I’ve lovingly pined for and miss on Windows – and a package management solution is one of them. Luckily, there are a couple of solutions to this, and best of all, both are open source and free. Read on for more.

The Premise Behind Package Management Systems

Linux distributions have had package management options for a while. You probably have heard of Red Hat’s RPM (Red Hat Package Management) format, Debian Linux’s apt-get, and then the new yum package manager that seems to be infiltrating a lot of distributions these days. At their core, these package management systems seek to achieve the same objective: analyze a system, determine what packages are necessary to run whatever software the user is requesting, find the latest compatible version of all of the packages, and install them in the correct order, ensuring they get laid down on the system successfully and that, after the 117 dependencies install, your text editor of choice is ready to run on your target system. I kid, but only a little bit.

Imagine bringing this over to Windows. Imagine the scenario: you are moving to a new system and setting it up properly, exactly how you like it. In the process, you are trying to find the latest version of Notepad+, for example, or any other reasonable popular utility. As it stands now, out of the box, you would Google for the site, find the download link, skip past all of the “featured offers” and near malware that most sites like to bundle with their downloads, and then run the installer. After that, you might even discover you downloaded a 64-bit version when you installed a 32-bit version of Windows. Or maybe you found an old download link, and there are two newer versions out there. That whole sequence is not exactly rocket science, but it is trying.

Imagine, instead, that you could simply say

choco install googlechrome

from a PowerShell command prompt and you would get:

…which would be followed by a completely functional installation of Google Chrome. That would save a lot of time, right?

And what if you had software installed like Google Chrome and then wanted to upgrade it? What if you could use a command like

Choco upgrade googlechrome

…and get an instant upgrade?

That is the power of package management, and that is what the Chocolatey package manager brings to Windows: a greatly expanding selection of carefully curated and maintained software packages that can be brought down and installed on your system with a simple three word command. As of this writing, there are 3,958 community maintained packages, and you can browse and search among them on the web at https://chocolatey.org/packages.

Where Chocolatey really comes in and shines is in the process of setting up and deploying new machines. If you have a fairly standard set of tools – Office 2013 or the 365 version of Office ProPlus, along with some other utilities like 7Zip, your web browser of choice like Mozilla Firefox or Google Chrome, and a few others, then you can absolutely script the setup of a new machine. Just deploy Windows through whatever method you care to use, and then once you have completed the installation and are at an administrative desktop, simply kick off a script that installs Chocolatey and then calls all of your software. Now you can get 70-90% of your software installs automated without having to do a bunch of imaging and packaging yourself, and all of the installations are done in a consistent, repeatable, reproducible way—another benefit of scripting in general.

Understanding the Pieces of the Chocolatey Puzzle

First, let us understand how all of the pieces fit together in this package management puzzle.

  • Chocolatey is a package manager that works with Windows – specifically, that is any version of Windows 7 or later that also has PowerShell installed. This is the vast majority of clients in production environments today. It uses scripts, along with a specific software package format (more on that in the next bullet), to install applications on your system.
  • NuGet is that specific software package format. It has previously been used by Windows software developers to install software dependencies for their own development projects. These were typically libraries, bootstrap utilities, and more that existed as complete packages out on the Internet, ready to be re-used. NuGet was simply an easy way to get those dependencies put in the right place within individual products.
  • PowerShell is the command engine that makes the whole thing tick. It functions as the scripting language and execution environment for all of Chocolatey. Chocolatey uses PowerShell to grab software, packaged in NuGet format, to install applications for your entire system, not just development projects.

To get started on a test system, use one command, straight from the regular command prompt (be sure you have administrative rights to do this):

@powershell -NoProfile -ExecutionPolicy Bypass -Command “iex ((new-object net.webclient).DownloadString(‘https://chocolatey.org/install.ps1’))” && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin

This one line of PowerShell actually does quite a few things, as you might expect. Let us walk through them individually.

  • It supersedes any custom profiles you have configured so as to ensure a full namespace is available to this command.
  • It sets the execution policy for just this one command to Unrestricted so that scripts that are downloaded from the Internet (in the case of this command, that is https://chocolatey.org/install.ps1) can be executed and not be treated as potentially malicious).
  • It downloads that .ps1 script from the Chocolatey website, which is a preconfigured set of instructions that PowerShell can use to install the Chocolatey system on your local machine.
  • It also sets a PATH entry to the default binary folder for the Chocolatey install, so that you do not have to enter the full path to the Chocolatey commands every time you would like to do any package management tasks. Instead you can just enter “choco” and then whatever you need, and Windows and PowerShell will know where to find it.

The Chocolatey installation process requires the .NET Framework version 4.0 and will attempt to install it automatically as part of that PowerShell script. I have set this up on Windows 7 and Windows 8.1 machines and that automatic installation of .NET was totally successful, although some administrators have a deep rooted aversion to installing multiple versions of the .NET Framework on systems due to potential application compatibility issues and the attendant security patching that is required for each respective version. However, this is an all or nothing proposition, and I think the benefits of Chocolatey outweigh the negatives of another framework version deployed.

Chocolatey in Action

Chocolatey is essentially an automated deployment wrapper. It does not intercept installations or somehow modify the setup process of an app. Rather, it automates the downloading of a setup file or package and then its execution, while turning off any sort of screen communication from the app (a silent install).  Here is an explanation direct from Chocolatey that goes into a little further detail:

“Chocolatey is a software management tool that is also a package manager. It functions fantastically well when the software is all included in the package and it doesn’t make use of native installers. However to approach the Windows ecosystem a package manager also needs to know how to manage actual software installations, thus why Chocolatey does that as well. For publicly available packages, copyright keeps from having binaries embedded in packages, so Chocolatey is able to download from distribution points and checksum those binaries.”

Some tips:

  • The command cinst works instead of choco install to save you some keystrokes and avoid carpal tunnel syndrome. So choco install googlechrome could also be cinst googlechrome.
  • Choco uninstall packagename removes a package from your system. It only removes the Chocolatey installed instance, so if for example you have a previous Git installation, then install Git from Chocolatey, and use choco uninstall git to uninstall one of your Git deployments, it will remove the Chocolatey installed instance.
  • Want to search for packages but do not want to browse the web? This is common on new server installs. Use choco search packagename to search the Chocolately package feed.
  • The command choco outdated will give you a list of all of the packages on your system that have a newer version available from the repository.

The Downsides of Chocolatey

As with every tool, there are negatives. Here are the most important ones for Chocolatey.

  • There is a malware risk to Chocolatey, however slight. Unless you run your own packaging team and set up Chocolatey’s PowerShell scripts to only retrieve packages from your own private repository full of packages you have vetted and trust, you will not be able to remove from your security mind the idea that you are downloading packages from a third party source. Those packages could well have malware in them, put there either on purpose by a nefarious actor in the contributor and maintenance team or, much more likely, the Chocolatey repository was hacked and malware payloads were inserted into the packages. To my knowledge and as of this writing, this type of breach has not happened to Chocolatey. But “has not” is not the same thing as “could not” or “will not,” and so there will always be a risk. On the flip side, Chocolatey is very popular and most of the package maintainers are very diligent about their work. Since the whole shebang is open sourced, the “many eyes” theorem means that problems and breaches would be discovered quickly and mitigated quickly, and the resulting reporting would be transparent. Caveat emptor.
  • Package maintenance is not always quick. Remember, Chocolatey depends on a team of volunteer contributors to package up applications. When new versions of the core applications are released, it is not an immediate process to package up the upgrade and make it available in the Chocolatey repository. For more popular applications like web browsers and some utilities, this is not a big issue—for one that software generally has the ability to update itself, making Chocolatey’s upgrade function a moot point; but the more popular the application is, the more active the Chocolatey package maintaining team for that application generally is. The wait for more obscure packages could be quite a bit longer, or packages could be left abandoned after several years.
  • Sometimes install locations get screwed up and there’s no way to track it. Because Windows lets software developers lay their bits down on users’ drives pretty much wherever they please, you wind up in situations where Chocolatey wants to put a particular piece of software in one location but the GUI installer you would download from the Web wants to put the software in another location. Herein lies the problem: if you install something outside of Chocolatey, especially if that software installs itself in a directory or folder Chocolatey does not know about, then Chocolately will not think you have that software installed—so it will let you go choco install thatpieceofsoftware and suddenly you have two installations of the same product on the same system. Sometimes that is not a big deal, whereas in other situations, it cripples the software.

For Windows 10, There is PackageManagement

Part of the innovating happening in Windows 10 and Windows Server 2016 is the Windows Subsystem for Linux, or WSL. This is essentially a port of Ubuntu Linux and other popular Linux distributions to Windows in a way that runs those Linux distributions as “layers” or subsystems underneath the regular Windows 10 user experience. Regular Linux binaries work and you can even install the X Windowing System and get separate graphical shells happening. (Who would have thought the year of the Linux desktop would actually be brought to us courtesy of Microsoft?)

This means that the plumbing is already inside Windows 10 to be able to provide a native package manager that works with PowerShell and Linux binaries, opening up a second entire ecosystem of applications to run on Windows 10 machines. That package manager is called PackageManagement, creatively, and it works with Chocolatey repositories, too. In fact, it is more of a package manager manager, because it works with multiple repositories and brings all of their capabilities and inventory together with a single tool.

To verify that PackageManagement is set up on your system, open a PowerShell prompt with administrative credentials and then type in the following command:

Get-Command -Module PackageManagement

Then, take a look at the universe of commands you have available to you.

To find out what repositories work, then call the following command:


You will probably find that only the regular PowerShell gallery is there. We can add the entire Chocolatey repository with one single command:

Get-PackageProvider -Name Chocolatey

To use the Chocolatey source repository by default, use this command:

Set-PackageSource -Name chocolatey

Now let us try to add some software. We can continue to use Chrome as an example. From the Get-Command example above, we saw that there is a Find-Package command which ought to find a package in a repository. Let’s search for Chrome:

Find-package –name Chrome

In the results, you will see quite a few responses, all of them packages of Chrome that are available in Chocolatey repositories. You can install any one of them by using the install-package command:

Install-Package chrome

Unfortunately, one of the really nice features of raw Chocolatey, the upgrade command, is not available with PackageManagement. Perhaps one day this will be available, but for now, this is only useful to install or remove packages. And again, PackageManagement (which, for future reference, was codenamed OneGet during Windows 10’s initial development) is only available for Windows 10 and now Windows Server 2016, because it is dependent on the Windows Subsystem for Linux, which will not be backported to earlier versions of Windows. It is also important to note that OneGet can co-exist with Chocolatey so you can use whichever option makes the most sense. It is a very nice tool to have in the arsenal and one that especially for power users and developers can make quick work out of application installation and maintenance.

The Last Word

I suppose the best way to sum up Chocolatey is: it’s one of those tools where if you need it, you know as soon as you see it that you need it, and you want it right now. I’ve long searched for a lightweight tool (read: NOT System Center) to script software installations and make it easier to stand up development and test environments with the right programs and utilities. Bonus points that Chocolatey uses PowerShell to get its work done. Check it out now. http://chocolatey.org.

Next Generation Authentication for Windows Shops

An edited version of this story ran on Computerworld.com on September 13, 2017. Credit: Computerworld

Authentication. The act of proving one’s identity to the satisfaction of some central authority. To most, this process means typing in a user name and a password, and it’s been this way for years and years.

But passwords—especially the passwords that most enterprises require that have to be complex, with long strings of numbers and specially cased phrases with some (but not all! Heavens no, not the one you want) symbols—are difficult to remember and often end up getting written down on sticky notes. Then you have to reset them every so often so that hackers and crackers are working towards moving targets. Passwords can be leaked or hacked from the inside as well, as we have seen with numerous credential dump attacks over the past few years. And users can accidentally disclose their passwords if they fall victim to ever increasingly sophisticated phishing attacks.

Luckily for Windows shops, Microsoft is innovating in this space and it has introduced an enterprise quality method of using biometric identification and authentication without requiring the purchase of specialized hardware—and it is baked right into Windows 10, which many shops are already beginning to deploy to replace Windows 7 and Windows 8 and 8.1. In this piece, I want to take a look at this innovation, called Windows Hello for Business, and show how it works and how to enable it to secure your enterprise while eliminating the need for your users to handle cumbersome passwords.

Windows Hello for Business

Windows Hello is the most common and most widely known of the biometric authentication schemes that Windows supports. Windows Hello for Business takes the Hello idea and bundles it with management tools and enforcement techniques that businesses and enterprises want to ensure a uniform security profile and enterprise security posture. Windows Hello for Business uses Group Policy or mobile device management (MDM) policies for management and enforcement, and uses key- and certificate-based authentication in most cloud focused scenarios for maximum protection.

Essentially, Windows Hello acts on two fronts: it can scan one’s fingerprint, and it can also take an infrared picture of a user’s face and perform analysis on it. It pairs these unique physical attributes of each user with cryptographic keys that replace passwords as authentication methods. These keys are stored within specialized security hardware, or are encrypted in software, and unlocked only after Windows deems them authentic. For organizations uninterested in biometrics, Windows Hello also supports PIN usage to replace passwords transmitted over the network.

Windows Hello protects Microsoft accounts (the accounts you use to log in to Microsoft cloud services, Xbox, Office 365, and the like), domain accounts that are part of a corporate Active Directory deployment, domain accounts joined to an Azure Active Directory domain (these are relatively new), and in the future, accounts protected by federated identity providers that will support the Fast ID Online (IDO) 2.0 protocol.

Why is Windows Hello considered stronger than a traditional password? For one, security is always better in threes—the best method is authenticating is to prove something you have, something you know, and something you are. In this case, Windows Hello can authenticate users by satisfying all three rules: something you are (your face, which is exceedingly difficult to copy and use in a malicious way), something you know (the PIN that is used by default by Windows Hello from the point of registration onward), and something you have (your fingerprint, which again without removing digits is difficult to copy and use nefariously).

What is most interesting is that all of these biometrics are stored on the local device only and are NOT centralized into the directory or some other authentication source; this means credential harvesting attacks are no good against Windows Hello-enabled accounts simply because the credentials do not exist in the place that would be hacked. While it is technically possible each device’s trusted platform module, or TPM, could be hacked, an attacker would have to crack each individual user’s machine versus simply executing a successful attack against one machine: a vulnerable domain controller.

The security techniques involved in verifying the biometrics are rigid: special webcams or cameras designed to see in infrared can pick up the differences between a photograph of a person and the real presence of that person, and most laptop manufacturers are now including Hello-compliant cameras in their corporate lines of devices now. You can also purchase these compliant cameras separately, making a staged rollout possible. Fingerprint readers are mature technology and have been around for years, but Microsoft indicates the newest generations of readers pick up more and more on the first swipe, eliminating the need to swipe again and again like some previous models required; essentially all fingerprint readers compatible with any version of Windows can also be used with Windows Hello. It is important to note that you can use both fingerprints and facial cameras or both solutions—whatever biometric you end up using is called the “gesture,” and the gesture action is the key that begins the unlocking of public and private keys and verification of a user’s identity.

The Registration Process

To use Windows Hello, you must register your user account so that Windows can generate the proper elements to replace the traditional password. First, the user configures an account on the device (or the administrator adds a user account to the device). The user authenticates the normal way during the registration process—using a user name and password—and the authentication source, most likely Active Directory, issues its standard yay or nay to that user’s credentials. The user can then enable his or her PIN, which then becomes inextricably linked between that device and that user account.

Windows then generates a pair of keys, a public half and a private half, and stores them both either in the hardware TPM module, or if a device does not have a TPM, it encrypts the keys and stores them in software. This first key is associated with just one biometric “gesture” – either a fingerprint, or a face, or a PIN. Each subsequent gesture has a different protector key that wraps around the authentication key. While the container is designed to only have one authentication key, multiple copies of that single authentication key can be wrapped up with the different protector keys associated with the different gestures registered on the device. There is also an administrative key that Windows automatically generates so that credentials can be reset when necessary, and the TPM has its normal block of data as well that contains attestations and other TPM-related information.

After the PIN is established and these keys are created as I just described, the user can authenticate to the device in a trusted way and Windows will then let him or her create a biometric gesture like register a fingerprint or face print.

Enforcing Windows Hello for Business through Group Policy

As you might imagine, you set up Windows Hello and enforce it throughout the enterprise organization through the use of Group Policy. Within the Group Policy Management Console, you can find policy settings under Policies / Administrative Templates / Windows Components / Windows Hello for Business in both the User configuration and Computer configuration hives. The important policies to configure are:

  • Use Windows Hello for Business: you’ll want to set this to Enabled to get started with the deployment.
  • Use biometrics. Set this to Enabled to enable gestures instead of supporting only a PIN.

Alternatively, if you already have a mobile device management solution deployed, then you can use MDM to force the deployment of Windows Hello. The policies use the PassportForWork configuration service provider, which is like a template of potential settings that you will need to import into the MDM solution before you can begin configuring and enforcing policies.

Key Points to Consider

Some important points to remember:

  • Credentials enrolled in Windows Hello for Business can be bound to individual laptops, desktops, or devices, and the access token one gets after successful credential verification is also limited to that single device.
  • During an account’s registration process, Active Directory, Azure AD, or the Microsoft account service checks and authenticates the validity of the user and associates the Windows Hello public key to a user account. The keys—both the public and private halves—can be generated in the TPM modules versions 1.2 or 2.0 or they can live in software for devices without the right TPM hardware. The Windows Hello gesture does not roam between devices and is not shared with the server; it is stored locally on a device and never leaves the device When the PIN is entered and the face and/or fingerprint is applied, Windows 10 uses the private key stored in the TPM to sign data transmitted to the authentication source.
  • According to Microsoft: “Personal (Microsoft account) and corporate (Active Directory or Azure AD) accounts use a single container for keys. All keys are separated by identity providers’ domains to help ensure user privacy.” In practice, this means that keys get commingled within one secure container, although they are delineated by their native identity provider so that the wrong key is not sent to the wrong provider.

Sidebar: Why a PIN and not a password?

At first blush, a PIN seems like a password but worse: shorter, probably all one type of character (usually numbers), and most likely reused among a number of different places, including bank accounts, access to your mobile phone or tablet, and so on. However, the technical execution of how passwords are verified in the authentication process makes all the difference. Passwords are transmitted over the network to the authentication source where they are validated and either accepted or rejected. Because this transmission happens over the network, anyone with the right tools can snoop in, capture the credentials, and reuse them anywhere. And as we discussed earlier, if all of the passwords are stored centrally, one attack can potentially compromise all of the passwords. In Windows Hello for Business, the PIN is the gatekeeper to unlock a cryptographic key that is bound to the TPM in one individual machine. The PIN only works on the local device and does not enable authentication of any other kind from any other place.

Active Directory Requirements

Fully enabling Windows Hello for Business will most likely require you to add at a minimum one Windows Server 2016 domain controller to your domain. While you do not have to raise your domain or forest functional level, the 2016 DC will light up some required authentication functionality. One alternative to shelling out for a 2016 license is to use Azure Active Directory to deploy Windows Hello.

There is detailed information about exactly what is required from a prerequisite standpoint on the Microsoft website: https://docs.microsoft.com/en-us/windows/access-protection/hello-for-business/hello-manage-in-organization  In particular, pay close attention to the key-based authentication requirements and the certificate-based authentication requirements; if you already have a public key infrastructure deployed in production, the certificate-based authentication method will be much easier to start with. If you are largely cloud oriented, then the key-based authentication method is the one to go with for your first Windows Hello deployments.

The Last Word

Security experts for years have been calling for the death of passwords as we know it, but that prediction has always been troubled by the lack of a seamless, affordable, user friendly alternative to authenticating against systems. In practice, it was always going to take Microsoft putting biometric features inside Windows, the most popular operating system, to spur enough organizations to look into passwordless authentication, and it appears with Windows 10 that the Redmond software giant has done Just Enough to warrant the attention of enterprises everywhere. While it is unlikely your shop is a position to remove passwords entirely, new machines you deploy can work with this option by default, and as you migrate to Windows 10 over time at your own pace, you can slowly but surely work Windows Hello for Business into your security profile.

Is Windows to Go a Good Solution for the International Airline Laptop Bans?

An edited version of this story ran on Computerworld.com on August 8, 2017. Credit: Computerworld

Often Microsoft presents technological solutions to problems that only a tiny percentage of its customer base has. Windows to Go was just such a feature—a nice solution to a problem that was virtually non-existent back when it was first released in 2011. However, six years later, that non-existent problem could very well be widespread.

What is Windows to Go? It’s a way to take a Windows installation with you on a USB thumb drive. You pop that thumb drive into any computer, boot from the USB, and your personalized installation of Windows—with all of your applications and files and access to corporate resources—is there. When finished, shut down, unplug the USB thumb drive, and away you go. It’s essentially portable Windows.

Windows to Go becomes more attractive in a world that seems to find traveling with electronics to be a security threat. You probably recall the recent news of the ban on laptops from all flights entering the United States from both selected Middle Eastern countries, as well as, more recently, flights coming from Europe. While this ban was lifted, more stringent security protocols are reportedly being developed for both domestic and international flights.   We could soon be entering a world where laptops are either checked in the baggage hold at airports without fail or not brought on trips at all—or a world in which officers at ports of entry demand access to electronics for either cursory or in-depth examinations. Having a nice USB thumb drive tucked away somewhere could be a real asset.

Having laptops subject to examination, or possibly locked away outside of an employee’s purview, has obvious implications for enterprises around the world. Many organizations have security policies that prohibit employees from leaving their corporate laptops unattended. Many organizations do not, as a matter of policy, encrypt the local hard drives of laptops they issue to employees. (This is very obviously a mistake in today’s world, but that does not change the reality of the situation.) Many organizations send field workers into some very remote and insecure areas of the world, often with real business assets and trade secrets stored in digital form on workers’ laptops.

These types of security protocols make it more likely that you will be separated from your laptop. Your business travelers have to put notebooks with company secrets somewhere else not within their direct control and they have virtually no say what happens to those notebooks when they are outside your travelers’ fields of vision. For most enterprises, this is far too much risk.

But that risk is a lot lower when you take Windows with you on a thumb drive and worry about the actual PC you use whenever you get to where you are going. Let’s learn a little more about Windows to Go.

What is Windows to Go?

Windows to Go was introduced in the Windows 8 release wave as an alternative to virtual desktop infrastructure: it is essentially a portable, entirely self-contained installation of Windows that you use on a USB thumb drive—that drive needs to be USB 3 in order to have the read, write and data transmission speeds necessary for a modern computer to run an operating system off of it. But what you end up with, after you configure it properly, is an entirely self-contained computer for a knowledge worker that is encrypted and fits in one’s pocket. You can pop it in your travel bag, in the car, even in your socks (if you are that type of person) and all you need to do is plug it into any reasonably modern PC, boot off the USB drive, and your OS, documents, wallpaper, personal settings, applications, and everything else is right there for you. This copy of the OS is managed through an IT department and thus it can have VPN software on it, or if you have configured DirectAccess, that copy of Windows can reach out over the Internet and retrieve its managed settings, Group Policy object configuration, and so on.

There are some key differences with Windows to Go, in its default configuration, as opposed to a similar copy of Windows installed on a regular fixed drive in a PC as you have come to expect:

  • The local drive in the computer on which Windows to Go is run is hidden by default. This keeps whatever crap is on the local system from seeping its way onto the Windows to Go USB drive as well as helps users properly save and retrieve documents to the USB stick. You can disable this functionality, but it is more secure to leave the hiding feature on.
  • Upon the first boot on a new Windows to Go target computer (that is, the “guest hardware” into which you plug the Windows to Go USB stick), a process goes through and identifies the right hardware drivers for the target system and enables and installs them. This process may reboot the computer several times, after which the boot process will proceed straight into Windows.
  • Windows to Go detects drive removal. Windows in this configuration will pause the whole computer if it detects the USB drive is gone and then will shut itself down after 60 seconds if the USB drive is not reinserted into the target machine. This is to prevent folks from using their copy of Windows to Go at, say, an airport kiosk and then quickly just removing the stick without shutting down the computer—a scenario in which bad actors could then access a logged in corporate desktop. With this feature, the whole computer shuts down rather than leave access open for others. If the USB drive is reinserted within 60 seconds, then operation continues as normal.
  • Access to the Windows Store is disabled by default, but it can be reenabled through a Group Policy object change.


Otherwise, Windows to Go behaves identically to Windows fully installed on a fixed computer. The added convenience is simply that you can unplug the stick and migrate it to any other device in the future.

Deploying Windows to Go

It is not much more work to deploy Windows to Go than it is to release images of any version of Windows these days—your current toolset like DISM and ImageX will work just fine. All you need is the correct USB drive hardware, a Windows Enterprise image, and a Windows Enterprise host computer to write and provision the Windows to Go image to the USB stuck. It is possible to scale this deployment process using some PowerShell scripts so that you can make multiple sticks at once, in case these new regulations have caught you off guard and you need a solution, like, yesterday. There is a very comprehensive guide to deploying Windows to Go USB sticks on TechNet, including these scripts, and I heartily recommend walking through the process so you get a feel for the steps needed to complete the provisioning. ] http://social.technet.microsoft.com/wiki/contents/articles/6991.windows-to-go-step-by-step.aspx]

After the sticks are created, you just hand them out to your users and tell them to boot off of the USB. You can see where this will come in handy in these banned laptop scenarios—there is no ban on a USB thumb drive, so you have a couple of options:

  • Take a loaner laptop with you that has no operating system installed at all—in other words, a bare metal laptop. You can allow that to be checked according to the airline’s procedure. When you arrive at your final work destination, plug in your thumb drive, which has never left your possession, and carry on. Of course it could also have a simple installation of Linux or Windows on it; it really does not matter as you would never boot into it.
  • Use Windows to Go in a business center at a hotel or convention center. Since the computer reboots to boot into Windows to Go, you don’t have to be concerned with software keyloggers or other runtime based malware. Of course it is possible for a hardware keylogger to be installed on a keyboard so you must weigh your current acute need for computing access against the threat profile you and your business have identified.
  • Purchase burner equipment at your final destination and return with it or destroy it. You can pick up any cheap laptop at any office supply store and it would be sufficient to run Windows to Go. If you are going to a reasonably populated area, $200-300 can be invested in a cheap laptop into which you can then insert your bootable stick and be off to the races. You can then either bring the laptop home with you or dispose of it—for maximum security this is a good option.


There is currently a list of officially supported Windows to Go USB drives which you can find at the Microsoft website [https://technet.microsoft.com/en-us/library/f82d1a0a-d8f7-4e8a-86a6-704166969a42(v=ws.11)#wtg_hardware]. I can recommend the IronKey Workspace W300, W500, and W700 options in particular as I have hands on experience with those models, and they have additional security features like boot passwords and self destruction capabilities for hard core security buffs. However, you can use devices that are not officially certified and most likely they will work fine as long as they are USB 3 devices. In fact, one of the officially certified devices—the Kingston DataTraveler—is off of my recommended list because it became scorching hot in my tests after less than an hour of usage in a Windows to Go scenario.

Licensing Windows to Go

Of course the brilliance of this solution technically is obscured by the money grab that is Microsoft licensing, except given recent current events, businesses may have little choice but to pony up for the additional expense.

Windows to Go is part of the Software Assurance program, that bundle of additional benefits and license flexibility that you get by forking over about a 33-40% premium on top of the cost of the license in question. The benefits of SA differ depending on whether your license is for a consumer or a server operating system and also whether this is for server application software or business applications like Office.

For operating systems, Windows to Go is part of the Windows SA benefit package. But of course you also have to decide if you want to license per device or per user. If you are licensed per device with Windows SA, then you can use Windows to Go on any third party device while off site. If you license Windows SA on a per user basis, then you can use Windows to Go on any device. You can also with both methods use Windows to Go on a personally owned device, but not while you are on a corporate campus. (This has to do with roaming benefits, or the ability to take a copy of the software you use at work and put it on your home machine.)

The Last Word

Windows to Go may have been ahead of its time, but it is certainly a competent solution for organizations that have more than a few regular international travelers getting caught up in these recent laptop bans. The great thing about using Windows to Go in these solutions is that it maintains your security profile, is only minimally more inconvenient for your traveler, and is easy to retire if and when these bans are ever lifted. Give it a look.