Course Transcript

1.

Alright, now time for one of my favorite topics and that's deployment. Now deployment is a really expensive area for a lot of IT organizations. There's maintaining the image, there's deploying the image. There is, you know, managing our infrastructure. So what we want to look at here is the old and the new. And that is we are going to talk about building a Windows 10 Image using the existing infrastructure – using existing tools. There are also some new features that can potentially save your organization some money. So things like provisioning and the emphasis now with Windows 10 and the improvements in the upgrade scenario. So a lot to talk about on this section, I am looking for to talking about with you.

Back to top

1.

There is an old proverb that says, "A king counts his cost before going to war," or as my personal finance instructor said in high school, "Prior planning prevents poor performance." Well, that can be applied to deployment. There are lot of important considerations to think about before you jump into a new operating system. And Windows 10 is no different. So I want to talk to you about some deployment considerations. Now, for starters, there are some key considerations. And all of these things that you see on this screen are impact areas. And this includes things like the business case, and of course, the importance around user training. Now one of the things that I find is sometimes these things get a little overlooked. For instance, the business case is an important area to stop and start with. The reason I think that's important is because there are a lot of features in the new operating system and you want to account for those. Think about those and decide if you're going to include those as part of your user training and as part of your infrastructure and support or is it something you are going to disable or not actually implement. Let me give you an example. When Windows 7 was released, a lot of companies found out that, "Hey, there is IP version 6 in the stack." And they would go around and they would turn it off because, oh, they didn't think they needed it. Only they discovered years later, there is actually some technologies in Windows 7 that are dependent on version 6. Now this isn't Windows 7. It's Windows 10. But the principle still applies – learn Windows 10, understand it, look at the different features and decide for yourself what features you want to include as part of your business and what features you don't want to include and don't want to support.

Other key consideration areas include applications and infrastructure support and user data. All of these areas are things that can affect your organization and cost you money if you don't stop first and do that prior planning. Now the first area I want to dig in a little bit more is hardware requirements. I want to make sure that your systems meet these minimum hardware requirements. Now the good news is that these hardware requirements are not much different as they were when Windows Vista was first released. You still only need a gigabyte of RAM for 32-bit systems, a gigahertz chip and so forth. However, there are some specific features that have additional requirements. So, if you want, for instance, to support Hyper-V, well you not only need the right edition – that's Windows 10 Pro or above, you also need to have the virtualization extensions and slot extensions in your processor. If you want of course to support touch screen, well, you have to have a touch screen interface. If you want to use a cloud-based account like a Microsoft account, or you're going to need the network access, you're going to need the account. And that's going to allow you to synchronize your settings. But, if you don't have this, then of course you're not going to be able to use that feature. If you want to use InstantGo, well that's a feature that requires connected standby hardware. And then there are other technologies that aren't even listed on this slide that have requirements. Say for instance, you want to use the Windows Hello feature, which is a biometric face recognition security software. Well, then you have to have a special camera, an infrared camera, or a Windows 10 certified fingerprint device.

So you need to become aware of what those features are and whether or not there are specific hardware requirements. And make, of course, your acquisition and procure your Windows 10 devices based on those features. And it goes back to carefully evaluating the business case around Windows 10. Now here is one important category, very important and that's application compatibility considerations. This is a big one because, of course, it's the reason we use Windows. It's for the applications. We don't use Windows for Windows. We use it to be productive and to use our apps and access our data. Now when it comes to application compatibility, well you don't have a whole lot to worry about when it comes to store apps because those apps are used to work in Windows 8. They are likely to work in Windows 10. And when it comes to desktop apps, well those are going to require some testing. And thankfully, Microsoft has a tool called the Application Compatibility Toolkit or ACT. You can download that, use the guidance from that, use the tools in there, inventory your environment, use it also to perhaps fix or shim as they like to call it, some of those applications. And then browser-based applications. You certainly want to pay attention to this because there is a new browser in Windows 10 called Edge. But there is also Internet Explorer 11. Regardless of which browser that your organization wants to use, you want to make sure that your Internet applications will work under Windows 10 whether it's IE 11 or Edge.

So there is a compatibility feature called Enterprise Mode. And so, before you actually migrate to Windows 10, you might need to evaluate those applications and ensure they are going to work. And that could include adding it to the Enterprise Mode list for compatibility purposes. So application compatibility is a big category to think about so that you can move to Windows 10 with the confidence that users can continue to access the apps they need. And you can continue to accomplish the mission of your business.

Back to top

1.

So how do you know if you're ready for Windows 10? How do you determine your readiness? Well, there are several ways you can do that. First of all, you want to ascertain and collect information and inventory your existing systems. And Microsoft has several different tools to help you to do that. Of course, you might have something in place already. But, if not, you might consider a PowerShell script that interrogates the WMI – the Windows Management Instrumentation – API in all your different systems. And they can report back and even build a spreadsheet or a report for you. So scripting is a possibility. Then Microsoft has some tools like MAP – Microsoft Assessment and Planning Toolkit. MAP is a free tool. I had been using it for years upwards into version 9 point something now. And with MAP, what you can do is evaluate your...and inventory your current systems, and then apply different scenarios like a deployment to Windows 10. And MAP includes reports and instructions and will alert you to different systems at need maybe a hardware upgrade here or there.

You also have available to you, ACT – Application Compatibility Toolkit. And not only it can be used for helping you identify application compatibility issues, potential issues, it can also be used to inventory your system. So, got a couple of different focuses. MAP is focused of course on the Windows 10 upgrade or deployment scenario along with some other scenarios. Whereas ACT is focused on the application compatibility space. Now, if you have a System Center environment, you might have Configuration Manager and its asset inventory feature and so you have a database there. And you can inventory and analyze your systems from that, or you might have a third-party option. The key point to this slide is you want to be sure, you know, what you are starting with and analyze your existing systems to help determine your readiness for Windows 10.

Back to top

1.

Now there is a new installation option with Windows 10. So when you do your inventory, if you discover that some of your devices are low capacity devices, then Windows 10 can be installed using a light-weight mode. Now what does that mean? Well, around the time of Windows 8.1, Microsoft developed what is called WIMBoot. And this is an evolution from that technology. What it does is it looks at the actual space on the machine that is installing Windows 10 to...if it finds that space to be limited and if it also determines there is sufficient memory and processing power, then it will actually install in a light-weight mode.

The translation, more room and the way it accomplishes that is it actually comes along, and it says, "Okay, well, let's install the operating system files, but let's compress them." So that's going to require additional processing power to decompress them. And then we look at the actual recovery image and we remove the recovery image. So we're not actually taking up space for, you know, the occasional recovery if ever. Now that doesn't mean that this system is going to run in a subpar performance. As part of the evaluation, it's going to take somewhat of a performance hit because it has to decompress those files but it should not affect the overall running of the device. Some of you might be wondering, "Well, what about this moving the recovery image? Does that mean I can't restore this installation if anything goes wrong?" Not at all, you can actually restore this installation. You are just going to have to use an offline image instead. So you would have your image on a USB or removable media and that's how you would actually recover this device. The benefit, of course, to the user is by reducing this amount of space and saving this space. Well, then there is more room to do stuff, right. There is more space for the music and the files and the work data and the photos and that kind of thing.

[Windows 10 achieves a small footprint by compressing system files and removing recovery images. System recovery is still available via a rebuild using runtime system files or an offline recovery image.]

Back to top

1.

Now another important area to consider and to evaluate is the how. How are you going to deploy Windows 10? And you might be thinking, "What do you mean? We deploy Windows 10 the same way we've always deployed Windows." Well, that's true. You could do it that way but Windows 10 has some new methods of deployment and that's what I want to talk to you about now. Let's look at the different deployment options we have available to us. Now here are our three categories. We have a traditional deployment option, the upgrade option and we have provisioning. Now, with traditional, we have, of course, the typical type of build process we've come to know and to love. This is one where we build a custom image – our gold image. This is very useful with bare metal deployments if we have a side-by-side or what we call a replace scenario. So replacing one desktop or device with another device and they're side-by-side or we're doing a wipe and load. So we might also call that a refresh or it has an existing operating system. And we're going to refresh it with Windows 10 – a new operating system. So the traditional process applies in both of those cases.

But we also have available to us an upgrade. Now some of you are thinking, "Upgrade?" Well, upgrade is going to require less effort than the traditional wipe and load and migration process here. It preserves everything and then here's a key point – it's actually recommended. I will get into more as to why it's a recommended approach here in a moment. I know there are some skeptics out there listening to me but maybe I will convince you here in just a few slides. But there is also a new kid on the block, that's provisioning. Provisioning will actually transform a device. It doesn't do an upgrade and doesn't apply an image. Instead, it applies a package of configuration settings and this is cool. This is a situation where a user can bring their own device and then you can make it enterprise ready by applying a provisioning package. Again, we will talk more about that in just a moment.

For starters though...so now what I want to do is look at this question right here. Why should I do an upgrade? And why should I consider an upgrade as a legitimate deployment option for my business? Now, in the past, I had some troubles with it. I don't know about you. I've been doing this a long time and hands down, the general opinion of IT pros that I've worked with is – upgrades are bad, reimaging is good. Windows 10 seeks to change all this. Now I realize upgrades are tricky business. And the way I often think of these is like those old Jenga puzzle games, you know, those block puzzles or pickup sticks. That is where you have these different items layered on top of each other and the operating system is kind of holding the whole thing up. And at any time, sliding out the OS and bringing in a new one, well that can risk everything else falling down kind of like this. If I was to draw this up on the board, imagine we have our hardware at the base and, of course, the operating system up above.

Now, if it was just the operating system that we were replacing, well it sits on top of the hardware. No problem. But that's not what we are talking about. We are talking about the fact that the operating system is actually a block right in the middle of our stack. On top of the operating system, we have data, applications, and settings. Upgrades are tricky because we're actually sliding this operating system block out and replacing it with a new one without affecting these other blocks. Now, with Windows 10, we are actually able to do this. And it has a lot to do with the way that the user state data is retained and how the process works. And it's dependent on evolving technology that Microsoft introduced with Windows Vista and they continue to improve with Windows 8. And here we are with Windows 10.

We're at the point now where upgrades are the most tested scenario at Microsoft and one that they're even going so far as to recommend. And if you're still a little precarious as to why you should consider an upgrade, think about the fact that the hundreds and millions of users that are out there using Windows 10, many of them if not most of them have gotten Windows 10 through the upgrade process. You see the answer to why you should consider an upgrade is a fourfold response. There are four key benefits to an upgrade. First one is the fact that it preserves settings. So all those blocks that we talked about that are up above, those applications, the data, the settings, an upgrade is able to retain all of those. That translates to secondly a smaller and faster process. Because it's a smaller actual process and it goes faster then we are not taking expensive amount of time and effort it takes to work up a new golden image and having to learn new tools in fact to support those images. There is also resiliency built into the upgrade process. So at anytime during the upgrade process, if you don't like the way things are going or if there is a failure of some sort, it detects a hardware compatibility problem. Or even after you install Windows 10 and you're like, "You know, I need to go back to Windows 7." Well, there is a rollback option available to you. And finally, another reason why this is beneficial is because you're not relying on the ADK and a lot of the tools required to maintain an image. Upgrades are just easier to do.

Back to top

1.

Now, even though the upgrade recommended, there are still going to be cases where a wipe and load is going to help you out and an upgrade is not available. And that includes some hardware factors. For instance, if you have a brand new device, a bare metal device, or you need to make a significant change like a disk change, or you're moving from BIOS to UEFI, same thing when it comes to operating system factors. There might actually be some architectural changes you want to make. There is no upgrade from 32 bit to 64 bit. So that would require a wipe and load. And same thing when it comes to application factors. If you have some significant changes that you need to make in terms of your application environment or a large volume of applications, you might need to still rely on a wipe and load or traditional deployment.

[Assessment and Deployment Kit is a supplemental download that contains a large suite of tools for deployment, application compatibility, user data migration, and system benchmarking.]

I want to talk to you about some of the tools and the solutions available for your deployment. Now, if you've been around Windows 7, Windows Vista, you're familiar with some of these acronyms. You've seen perhaps ADK or WDS before. The key thing I want you to walk away from when you look at this is that as I move to the right, the organization and the complexity of my deployment is likely to go up. So we've got a large organization here and smaller organizations here. And then there is an additional set of tools primarily to help me increase my automation. And, where I have automation, I am able to reduce my cost. And these tools help me do that. Now Windows 10 is no different. All of these tools are supported for Windows 10 deployments and they've been updated to support Windows 10. Now this includes the ADK. ADK is probably our most basic tool, the assessment and deployment tool. It's a free download. And it has a large suite of tools that help me when it comes to building an image or performing an upgrade. And so this includes things like the Application Compatibility Toolkit, the Windows Performance Analyzer as well as tools to help me build a custom Windows PE environment for actually capturing the images and servicing those images.

[Microsoft Deployment Toolkit is a supplemental download that automates the creation, management, and deployment of Windows images and contains additional scripts that automate Assessment and Deployment Kit.]

Now, in addition to the ADK, if I want to increase my automation and use a server-based deployment, I have some solutions there that run on Windows Server, such as WDS for the Windows Deployment Server, and MDT – the Microsoft Deployment Toolkit and I love the MDT. The MDT is great because it automates the ADK basically. It has a set of scripts in it. I think of it as kind of a deployment factory, helps me create, manage, and service those images from a Windows Server and deploying them through a deployment share. I can go further though, I can actually deploy my images using the help of System Center and Configuration Manager. And, if I'm a larger organization like an enterprise-size organization, that might be one of the ways that I manage my devices. Now Windows 10 fits into all of these categories. There is an update to support Windows 10 deployment with the MDT as well as an updated ADK, service packs to support Configuration Manager in Windows 10. And so, when I'm looking at what options I have available, a lot of it depends on what kind of automation that I need and the size of my organization.

Back to top

1.

So now the burning question is what can you do to get ready right now? Well, there are four things you can do. First off, begin evaluating Windows 10, begin to patch and upgrade your current systems to get them ready. Windows 7 needs Service Pack 1, make sure it has the latest hotfixes and service pack and so forth. In fact, you can start moving to Internet Explorer 11 now even as you're running Windows 7. So, if you've got line of business applications that are dependent on IE, you want to make sure it's going to be compatible when they run on Windows 10, so begin to upgrade to IE11. And then, of course, make sure all of the other applications that you have will also work on Windows 10. Application compatibility is a big deal and, of course, that's critical to your mission. So that's what you can start doing now to get ready. Of course when you're ready, when you have done that evaluation, then you need to decide what kind of deployment option you're going to pursue. And that could be a traditional approach for some of the reasons we talked about – bare metal device perhaps – or maybe you need to make some architectural changes, but keep in mind that an upgrade today is a recommended approach. We also have provisioning which I'm going to talk about some more a little bit later on. Provisioning is a new approach by applying configuration settings, not an entire image. So you've got more choices now than you did in the past when it comes to deploying Windows 10.

[Before updating to Windows 10, you should patch and upgrade your current system, upgrade to Internet Explorer 11, evaluate the Windows 10 features, and validate applications on Windows 10.]

Back to top

1.

So now let's have a look at how an upgrade works in greater detail. Of course, we have these concerns about an upgrade. We are concerned about whether or not the data is going to be there and persist for our users, concerned about it performing well. We are concerned about it being reliable and trustworthy. Well, Microsoft has responded to this. There was a lot of demand by customers to make the actual upgrade process easier. I mean, think about it. Every couple of years we are having to do a new operating system installation. And a lot of organizations don't like doing that so they delay and they delay and they delay because it's expensive. And so you might be one of those companies that just migrated to Windows 7 and just got off of Windows XP. And the reason why a lot of companies delay is because it's so painful to maintain the image and go through that deployment process. So Microsoft responded, in kind, trying to come up with a way to make moving to a new operating system easier and with a lot less friction and pain. And so they have tried to remove a lot of those barriers. And so these are some of the areas that we have concerns or barriers around actually upgrading. And so with Windows 10 we have an improved migration process, one that retains user data and can bring across applications. And of course, if there is a concern about any of these, the user can be prompted and alerted about incompatible drivers or applications. And there is also a rollback option available. So, if they encounter any issues, they can roll back.

Now, in terms of the performance, it's been improved. Upgrades go much, much faster. It can be driven from Windows update. And it's something that can occur in place. Now, one of great things about this is, Microsoft supports not just Windows 8.1 – the immediate predecessors to Windows 10, but the actual upgrade paths go all the way back to Windows 7. There is also integration with existing deployment technologies that support the upgrade. So you can perform a full upgrade from Windows 7 and Windows 7 Service Pack 1, integration with System Center and MDT. You also can, of course, upgrade from Windows 8 and from Windows 8.1 now with update. All of these are also supporting System Center and MDT. Now, for a fuller look at the upgrade options, let's look at this chart here. This is our upgrade matrix. And this describes for me what the initial operating system, the qualifying operating systems are to allow me to take advantage of this improved upgrade process. And this includes Windows 7 RTM, only supports though ISO media here, okay. So I can't actually do a Microsoft.com or Windows Update-driven kind of upgrade for RTM, but I can with Windows 7 SP1. And that's probably, if I have Windows 7, it is probably Windows 7 SP1 machine. Notice, there is also upgrade support from going from an older version of Windows Phone 8.1, if you happen to have those, moving to Windows Mobile 10, which is what I did. I had a Windows Phone 8.1 and I have upgraded it to Windows Mobile 10.

Back to top

1.

So now let's look in greater detail as to how an upgrade works. Now there are four stages. There is the down-level, WinRE, first boot, and final boot stage. Now, during the down-level stage, this is where we have a qualifying operating system running Windows 7, Windows 8, or 8.1. And that operating system is evaluated, it's inventoried, it's checked to determine whether or not we can actually complete this process or continue at least through this process. So compatibility is assessed. There is also at this stage a couple of actions that can occur. So, as a result of the inventory and the evaluation, items might be marked available for migration. Some items actually might be blocked from migration because they are known not to be compatible. And then there might be situations where the user is prompted. In either case, we're preparing if an upgrade is available for the very next stage, which is the WinRE stage. Now the WinRE stage is where we boot the system into a Windows recovery mode or a minimal operating system, okay. Both the new system and the old system are offline instead we're actually not in Windows 10, we're instead actually laying down the new operating system and then preparing this new operating system by injecting some drivers and doing some migration. The bulk of the migration though happens after that first boot. This is where the specialization phase occurs where the new Windows 10 operating system is specialized to the system, drivers are installed, applications are migrated, and user data might be migrated.

We have then our final boot which completes the migration. It finalizes the upgrade, it welcomes the user back. This is also the OOBE stage or the Out-Of-Box-Experience stage. Now, at any time during these four different phases, if something goes wrong, well we have available an upgrade rollback. Now, with the upgrade rollback, this is where the original operating system is restored because something happened along the lines. In fact, even if the upgrade completes, if the user wants to, they can go back, you know, restore Windows 7. This makes, of course, the whole upgrade process far more reasonable and trustworthy because you know you can rollback and go to Windows 7 if something goes wrong. So how do you do an In-Place Upgrade, that's the next question. In-Place Upgrade could be accomplished a couple of different ways. There are three methods here. First off and the easiest is to do Windows update, I should say. Now this can be done with Windows 7 provided you have a hotfix applied to it. So it supports Windows 7 and Windows 8 and this is ideal, of course, for consumers. If you want a little bit more control, you can manage the upgrade with setup.exe with some additional switches. This allows you to use slash auto colon upgrade along with some other ones. And then, of course, you can use a task sequence in MDT and SCCM. And what is nice about this is this allows you to automate the upgrade process.

Back to top

1.

So the next thing I want to talk to you about is Windows 10 Provisioning. Now Windows 10 Provisioning is a really exciting technology because there is a lot of expense and effort that goes into imaging. And this is designed to lower a lot of that overhead to simplify the whole deployment and adoption process for, you know, a new operating system. And because imaging is, you know, prone to a lot of man hours and requires a lot of effort and tools in maintaining the image. Well, that translates to a lot of cost and so some organizations will delay and delay and delay. While Provisioning is meant to help address some of those pain points and that is it can transform a device for business purposes, but to do that all without having to go to the effort of reimaging. Now how does that exactly work? Well, let's talk a little bit more about this. Windows 10 Imaging or Provisioning has several key benefits to this. First off is, it supports both mobile and desktop. So not just, you know, one variation or the other so you can create provisioning packages for both of these or you can tailor them specifically to the different editions. So a mobile package versus a desktop package. One of the things that I really like about it is that it provisions off-the-shelf devices. So that means the whole BYOD scenario or the CYOD scenario – the choose your own device – where you give your users a handful of devices to choose from. Well, you can provision these. Now that helps especially if it's a BYOD because you can't reimage the users personally-owned device, but you can still transform that device and apply corporate settings to it so that they can use it to access corporate data.

[Runtime provisioning transforms a device for business use without reimaging.]

Now a network is not required for this. So this supports offline scenarios and this is another key point here. Anyone can do this. So this is great because, you know, IT Admins don't have to drive out to that remote office and try to deploy Windows 10 to those two or three field machines. Instead, they can send an e-mail to that user who can then apply those configuration settings. And you might be wondering, "What kind of settings are we talking about?" We're talking about customizations and configuration settings that are specifically designed to enable that person to use that device to get work done. So, in the case of BYOD type of situations, well that could be where they actually need, you know, a certificate or they need a WiFi profile. Here are some examples of that. Here are some of the scenarios. So this can include things like a VPN profile so that they can dial-in and access that application or add the Root Organizational Certificate for that. It could also mean that maybe we need to apply some specific security to protect certain types of data that that machine might be interacting with.

We have the mobile worker. We have the worker who needs a reliable device where devices are being recycled, especially like schools and classrooms where they're going to be reused. Provisioning is ideal for that because that's a lot of effort to kind of reimage those machines every six months, every three months, every year depending, you know, of course, on the school year and the terms and such. But still that's a lot of devices there so provisioning comes along and helps us keep them up to date. Now these provisioning scenarios can be driven by very flexible methods. So, you know, you can deliver a package that contains these configuration settings to your mobile worker via an e-mail if you want to. And they can double-click on it or if it's a mobile devices, well potentially they can use an NFC connection, right or a URL. And so there is a variety of different ways in which you can actually distribute those actual customizations.

Here is a list of some examples of those types of customizations. This includes the deliverance of application settings, including line-of-business applications, Bulk enrollment to MDM. Now this is important because you might want that personally-owned device to then be managed in your third-party MDM solution or maybe Microsoft's Intune services. And so Bulk enrollment can be included as part of that provisioning and that configuration. Applying or distributing certificates. So you've got secure connections and speaking of connections – connectivity profiles, WiFi settings. Enterprise properties and policies. And then we've got other types of important configurations that can be included. We can distribute file-based assets, such as documents and specific videos or pictures, you know, maybe something that relates to what that device is designed to do. Maybe there are learning videos for students or maybe there are HR videos for corporate workers. Start menu and customizations and a whole handful of other important settings that support, of course, the intended use of that device. Now these are some example configurations.

[Some example configurations are as follows: 1. Applications: Windows applications and line-of-business applications. 2. Bulk enrollment into MDM: Automatic enrollment into the Microsoft inTune or a third-party MDM service. 3. Certificates: Root certification authority and client certificates. 4. Connectivity profiles: Wi-Fi, proxy settings, and e-mail. 5. Enterprise policies: Security restrictions, encryption, and update settings. 6. Data assets: Documents, music, videos, and pictures. 7. Start menu customization: Start menu layout and application pinning. 8. Home and lock screen wallpaper, computer name, drivers, and DNS settings.]

Back to top

1.

All right, so the next thing I want to do is dig into the details of how Windows 10 Provisioning works. Now, for starters, we've got a brand new set of tools that support creating these configuration settings and putting them into what is called a provisioning package file. The packages bend over all the settings and the profiles and the assets and those customizations we're talking about. But, in order to create that file, you actually have to have this guy right here – the Windows Imaging and Configuration Designer or WICD, right. That's kind of a fun acronym. Now where do you get WICD so that you can build these WICD packages? Now you do that from the ADK and along with, you know, the other kinds of imaging tools. Except with the provisioning, it's going to be a much simpler type of process. So there are some dependencies on some of the other tools that are part of the ADK. If you are not familiar with it, the ADKs are free download and it includes the Windows 10 version of it – this new tool called WICD.

Now, with WICD, what you are going to do is you are going to define what you want the package file to include. So this is where you are going to include any particular binaries, files, any certificates, even convert an older edition of Windows 10 like Windows 10 Pro. I should not say older but like a Windows 10 Pro edition and you want to upgrade a device to Windows 10 Enterprise, you can do that through this package. So all of that information – the settings, the profiles, the assets, the stuff right here – that's going to be applied through a tool, through the WICD tool and the output of that is this PPKG file. Now this is a couple of comments or points in regards to limitation of WICD. So, for instance, we are only running one instance at a time or running one project at a time. It's important to have your file-based assets locally to avoid generating errors. There's a mention here, the fact, that it supports IoT or Internet of Things images and also mentioned here of a need for a registry hack if you are running this from Windows 8.1, all right.

So now we've got this PPKG file, we've got our settings, we have our profiles and our assets so then we can deploy this. Now you can deploy this thing from a variety of different ways. It can be a URL and you distribute it that way. It could be distributed via e-mail and the user can receive it, then double-click on it and access it that way. It can be deployed to a USB device and removable media. You can use Near Field Communication or NFC, which is an interesting way to configure one device to another. With like a Windows Phone, I could connect it and tether it to a machine and then just click and drag the PPKG file on top of the phone. And the way that works is that there is a configuration service provider – CSP – running in Windows 10 that is designed to take these inbound configuration settings whether they be a packaged file or group policy and apply them to the device to make sure it's up-to-date.

Now, once it applies that PPKG file and those customizations, then you've got, you know, the configuration where you have your corporate data, your corporate settings, your applications, the corporate ID and the MDM and certificates and profiles. All of those things are running on that device and perhaps side-by-side with that personal device. Now see, provisioning is a really exciting innovation by Microsoft because in today's age, I mean, how many of you play Angry Birds and then the next moment you are checking your work e-mail. I mean, we work and we play on the same device. That's part of this trend they call the consumerization of IT and it's part of the trend associated with the BYOD. In the present day, this whole idea of transforming a device using a packaging file is real exciting because we are not wiping up the device and applying an image and maintaining the image, instead we are storing those configuration settings in a discrete file and applying them that way. And I mentioned this earlier but this is just a reminder that we can also continue managing that device and managing this whole column right here of corporate information and assets through MDM – mobile device management. That could be Intune or a third-party option.

Now this is a look at what is going on under the hood in regards to how this package format works. Now there is only a couple of things I want to draw your attention to. First off, we're actually applying this either using the built-in configuration provider in the operating system or we can actually apply our configuration settings during the deployment. So we're not limited to doing it after the fact – we can actually streamline this or slipstream, might be a better word, this whole configuration step using these package files as part of our deployment or even as a first boot. So it's embedded into the actual image. Another thing I want to point out is that Microsoft took a lot of their, kind of, legacy or traditional ways that they would configure a device using an answer file whether it's for the phone, which is this MCSF settings or this Windows SIM settings. And they have basically created a universal or converged or unified answer file format. That's what this whole process is about. It's Windows provisioning answer file. That's what this WPAF stands for. And that's what Microsoft is demonstrating here is that the package file is really the evolution of the answer file, but there's so much that you can do with it. You know, we're building it using this console, using either a command line tool or using the Wicd GUI tool. We are building this and we're supplying answers to it and then we are using that information to create a package file.

Back to top

1.

So the next thing I want to look at is how to actually create and apply those provisioning packages in a little bit more detail. So we already know that we're going to use the Windows Imaging and Configuration Designer to actually create the ppkg file. I want to point out that there is also a command-line tool that allows me to do this. I can also use ScanState. There is a special switch in the ScanState tool if you're familiar with ScanState, also part of ADK. ScanState in the past was used for user state migrations and you can still use it for that purpose. But, in capturing user state, you can also use it to capture information and have it used to input into a package file.

[Packages can be embedded or distributed at deployment or at runtime.]

Now the next question is how do you apply a package. Once I mentioned earlier, package can be embedded, in other words, when the machine is deployed with a brand new image and then on first boot then that provisioning process takes place. And, if you're like an OEM or a phone manufacturer or something like that, you might elect to do that is use the embedded approach. You can also do it as part of a task sequence – a step during deployment, also during runtime. So runtime provisioning where it's distributed to the user or through an MDM solution and then that machine is automatically getting those new corporate settings. If, for instance, you're going to perform these steps during runtime, here is a couple of examples of where that might take place. First off, you might actually double-click on the package file whether it's in removable media or on the shared folder or something like that as an attachment and then that will kick off the process.

[The Windows Settings screen is displayed. It includes multiple clickable options, some of which include System, Devices, Personalization, Accounts, and Privacy. The presenter clicks the Accounts option. The Accounts screen is displayed. It is split into two parts. The left-hand part includes multiple clickable options, some of which include "Your account," "Work access," and "Sync your settings." The right-hand part includes the details of the option that has been selected in the left-hand part.]

There is a command-line tool and a switch. It can actually be done from within the settings application. In fact, let me show you what that looks like real quick. It's not in provisioning directly. This path is correct but there is an additional step in here. So let me show you what that looks like. So, if I go to Windows settings and I go to Accounts there and then click on Work access, right here is where it says add or remove a package for work or for school. So that's an example where a user can actually go through the steps of applying a package right there from the Settings application. And then finally, we can also apply that package and have it automatically applied via System Center or MDT. Now there are a couple of things I want to point out in addition to this. Packages, as you might imagine, are very powerful because they contain so many customizations. So you can actually apply some security to this.

So, through policies, you can require that packages are digitally signed. And, if they're not digitally signed, we're not going to apply them. At the very least, a user can be given a warning saying, "Hey, do you really trust the source of this package?" And so that becomes an important part of the security and packages, of course, can be digitally signed. They can also be encrypted. So you would hate it, of course, if you had a package file that contained enterprise secrets or enterprise files in it and it's on a USB device and that gets lost, oh my gosh, terrible, right. So you want to protect your package files and the information inside of it and you can do that by encrypting it. So all that security is also included as part of provisioning. And so you can take advantage of that to ensure that this process is not being taken advantage of, and your users are applying configuration settings that they trust.

Now, if you wanted to apply a package to a mobile device, the procedure is similar. But there are a couple of differences with it. So let's talk a little bit about how you might do that. First off, you can kind of go and tap on the Windows button five different times and put it into kind of configuration mode. You can click and drag a package file if it's tethered via USB. You can use Near Field Communication which I mentioned earlier before. They can also be embedded as part of the first run experience or applied using these different methods at runtime, so very similar to applying a package file to desktop. And this means you've got options in regards to configuring Windows 10 mobile devices. Those devices that are seven inches or smaller, including phones, as well as those devices that are bigger than that and so that they can have all of the consistent settings access to their applications – the line of business applications that they need in order to do what they need to do.

So this I think is a great alternative – the ability to transform a device from being, you know, an off-the-shelf kind of configuration and transforming it and making it business ready without all of the pain and effort and the destruction that comes with actually having to reimage it. So key points to remember about the provisioning process is that we've got support for both mobile and desktop. We also have support for provisioning BYOD or off-the-shelf type of devices. Networking is not required. So this can be done online or offline and securely because we can encrypt these and digitally sign them to ensure we know where they're coming from and who created them and then anybody can actually do this. So, if they do trust the origin of that package, you can support kind of a self-service distribution and you can also use policies to govern the distribution and the adoption of your packages. So provisioning, I love it. It's something they consider as a way of avoiding having to reimage. It may not be the option you always turn to. There may be cases where you still need to resort to good old fashion imaging, especially for bare metal machine with no operating system on it. Nevertheless, provisioning packages can be married with the deployment process. So it's really going to change the way that you configure your systems and get them ready and handing a brand new machine to that new employee, provisioning packages can save your a lot of time.

Back to top

1.

Now there is a lot of great new things in regards to deploying Windows 10, such as the improvements in upgrade and provisioning. But right now, I want to talk to you about the installation components around Windows 10 for more of a traditional type of install. Now, when we are talking about installing Windows 10, we have multiple installation destinations. These are where we can put Windows 10 and lot of these are familiar to you. We have a hard drive and, of course, we support SSD drives as well, which are much faster than the platter-based disks but both will do. We can install Windows 10 to a virtual hard drive for virtual machines, but we can also install Windows 10 installation to a VHD file and boot to that. That's called Native VHD Boot. So there is an alternative option there and then we have also available to us the ability to install to Windows To Go. And that means we can install Windows 10 to a supported USB drive and boot to that USB drive and have full Windows 10 running off of that USB drive. And that's a great option if we've got contractors or temporary workers or even telecommuters. We don't have to issue them a laptop, we issue them instead a thumb drive and if they've got a compatible device whose hardware can run Windows 10, well then they can run it from USB stick, isn't that great? And then with Windows 10 we have a new installation source and that's IoT – that's the Internet of Things – and these are specialized cards, little mini motherboards that support all kinds of application whether it's an appliance or a gadget or some sort of device along those lines.

Now, not only do I have a variety of different installation destinations, I also have installation sources and this has to do with where I get the Windows 10 bits from. Now there is a lot of familiar places here as well. Now the traditional way is to pull it down from the DVD or an ISO. We can also pull those bits down from Windows update in the case of an upgrade and download an image that's already been kind of preconfigured in a VHD. I can either create one of those or download one of those from the Internet as well. I can also deploy Windows 10 and those bits from a network share or from a USB stick just as before and also a deployment server and this could be System Center or could be MDT – Microsoft Deployment Toolkit and a deployment share. So I've got a variety of choices in regards to how I want to deploy or get the bits and, of course, install Windows 10 on to my target devices.

What I want to do is dig further into the installation components. There are several components that we typically use when we're talking about a traditional installation. We are looking here at WIM images. The installation source is in what is called a WIM file and we have setup.exe. Setup.exe runs in a preinstallation environment called WinPE. Of course, we have to be able to boot into WinPE so there is a boot environment that contributes to the installation. We also have answer files that can help us automate the installation. Now, let me make mention of a couple of things here before we go much further and that is, if you are familiar with Windows Vista and Windows 7, you're probably not seeing a whole lot of new things here. And that's because the installation components in Windows 10 is built on the same components that they started developing back in the Vista and Windows 7 days just evolved, if you will, with some minor improvements. Now where you see the biggest changes with Windows 10 has more to do with the alternative to doing an installation, say through a provisioning process and a provisioning file or say through an upgrade. Our focus here though is on those traditional installation components. So, if you're already familiar with these installation components because you've been working with Windows 7 installs and deployments, then you might actually want to skip ahead and fast-forward. But, if you're new to these files and especially if you're preparing for Microsoft certification where there is an expectation you understand multiple ways to deploy Windows 10, then hang in there with me because we are going to dig into each one of these areas.

Back to top

1.

Now the first thing we're going to look at is this thing called a WIM file. What is a WIM file? Well, WIM stands for Windows Image Management file. And the idea behind a Windows Imaging file has to do with the fact that we're going to store those installation source files in a file-based container. Now, back in the XP days, all of our installation files were in these cabinet files. And there was this process of decompressing them, copying them over, and this whole installation procedure that was separate from the imaging process, which just laid a copy of the files down. With WIM files, we have the ability to apply an image-based installation. And this is the traditional approach – the conventional approach now. And so, if you were to take the ISO material and – whether you download that or you acquire that through, like, a USB stick – if you were to open that up, you would find in there a folder called sources. And, inside of sources, there are two important WIM files. First one, install.wim – that's got Windows 10 in it.

Now it depends, of course, on what additional Windows 10 that you've acquired. You might have multiple editions in it. Then again it might have one very specific edition in it. Nevertheless, inside this WIM file is Windows 10. Now did you hear what I just said? You can actually have more than one installation inside an image file. So you can have support for multiple editions. And the same is said about any WIM file that you create because you can actually create and generate your own WIM files. This just happens to be the WIM files that come in the actual media and in the sources folder. Now there is another WIM file here called boot.wim. And boot.wim is important. As the name implies, it can actually boot. And what is inside a boot.wim is a WinPE image. We'll talk more about that here in a moment, but that's a preinstallation environment where setup can actually run and where you can perform various servicing and maintenance tasks if you need to.

Now I want to look a little bit more at some of the details behind what a WIM file provides for us. Now let's look a little further into some of the key characteristics of a WIM file. We already mentioned that the WIM files are container for our operating system – our operating system files. But we also want to make mention of these key points over here – that it's hardware agnostic, that there are multiple images that can be stored in a single WIM file. So, with that, you have the potential Windows 10 Home and Windows 10 Pro editions both being stored in the same WIM file. You don't need more than one. Now that might mean that the WIM file can get rather large, but Microsoft counters them with the fact that it also supports compression and single instance storage because when you have more than one edition, well, there are a lot of files they have in common. So no reason or no need to list those files or store them two, three, four times. We are going to actually only store them once inside the WIM file and then reference them because a WIM file architecture is, you know, very similar to kind of like a file system and has pointers and tables inside of it.

[The Windows Image Management file format is a file-based image that contains the operating system images as well as other files. There are two types of Windows Image Management files. These are installation images and WinPE boot images.]

In fact, let's have a look at the architecture of a WIM file. So you can see here the way that it's structured is very similar to a file system. We have some headers and some tables where we can keep track of those different file resources. And a file resource is actually only going to be stored once, but we can reference it for multiple editions or multiple images. Now one of the other great benefits of a WIM file is this last point right down here – the fact that it supports offline servicing. Now the reason why offline servicing is so grand is because the imaging process in the bygone days was so time intensive. We would have to take the image and we would have to apply it to a new system and we would have to make sure it had hardware compatibility with the image. We don't have to worry about that so much anymore. So that's a benefit, but then we would have to go through the process of customizing it and then capturing it back into an image. And then if another change comes along, an update or a driver was forgotten, then we have to go through this process all over again. But those are the bygone days. We don't have to go through all of that pain any longer. Now we've got offline servicing. An offline servicing is so beneficial because we can actually mount this WIM file to a folder and we can add to it. We can inject drivers. We can add folders. We can inject language packs and so forth – whatever change we need to make to this. And we can do without the time intensive process of going through a redeployment and recapture the image. We can service it offline.

Now I really like this diagram for several reasons. First of all, it shows me the relationship my WIM file has to the other installation tools and other installation components. And it shows me that when I combine them, I can create a complete solution and an automated solution. The other reason I like this slide is because it also shows me that my image doesn't have to be in a WIM file. I can also store it in a VHD file. And normally when I see VHD, I think VHD, I'm usually thinking virtual machine. But you can actually deploy a VHD-based image to a system without virtualization. And we'll talk more about that later on. So my WIM file or my VHD file is an important contributor to the overall installation solution.

Now another important installation component is Setup.exe. And Setup.exe, its job is to apply a WIM file to a VHD or to a disk – to one of those installation destinations that Windows 10 supports. Now it can be automated with an answer file. So we can provide some customizations. And we can improve the speed or the changes we want to incorporate into the installation and do that ahead of time without having to do it in post configuration. And, when setup actually runs, it executes those changes for us and applies the file for us through a process called configuration passes. Now these different configuration passes are supported by other installation components beyond Setup.exe, but Setup.exe plays an important role. And it has, for instance, the WinPE configuration pass. During that phase, WinPE launches, which is kind of a mini Windows environment. Then Setup.exe can execute within that mini operating system. And then it applies some important early level kind of configuration changes like maybe the disk partitioning and so forth. But Setup.exe also executes in other configuration passes, other phases of setup. So, for instance, another phase would be the specialized pass where unique settings are of that installation is bound to that device. And then there is the OOBE pass or the out-of-box experience. And that's where we have the final cleanup of our installation and perhaps some other post configuration before the users are able to log on. So setup actually takes place in several configuration passes applying the WIM file and getting that system ready to run Windows 10.

Back to top

1.

Now another important part of the actual installation is being able to boot into Windows PE and then afterwards being able to boot into Windows 10. And so the boot environment is also an important installation component and, of course, an important part of the way Windows works. So now what I want to do is talk a little bit about the Windows 10 boot environment. So let's begin with a look at the overall boot process. Of course, we power the machine on, right. We turn on the virtual machine or we turn on our physical device. And so, at that boot phase, we have the actual firmware initiate. And we have two different types of firmware that Windows 10 supports – supports legacy BIOS and supports a newer firmware initiative called UEFI. Now, after we have those firmware execute, then we find our boot loader. And this can be basically the first sector on our boot media. So this is going to be our active partition. And inside that active partition is a pointer that references our bootmgr file. So, after we have bootmgr, then what we're doing is we're continuing with the specific Windows 10 process of launching the kernel. Eventually, we're going to have a fully running Windows 10 after drivers are installed and, of course, executed. And then we have any services that are initiated and any other components related to Windows that are found inside of the registry. This paints kind of the initial picture of what takes place when we first power on our system and the critical components that make up the boot process.

Now, to understand this, let's look at the specific Windows 10 pieces and where they live. We have up here components that live inside the Windows directory. So this includes things like the kernel and winload.exe. And winload.exe – its job is to load Windows to actually fire the kernel up. And, once the kernel gets executed, then we start looking into the registry and identifying drivers and services that need to initialize after that. And the registry kind of takes over and governs the rest of the boot process. But, in order to even get to that point, we have to be able to find winload.exe. And so that is where boot manager comes in. Boot manager's job is to read the initial boot information stored inside of another kind of registry file called the BCD. The BCD stands for Boot Configuration Data. And the Boot Configuration Data contains different instructions as to where to find winload or maybe other available operating systems if I'm dual booting or if I need to resume from hibernation or I need to run some low-level memory tester or boot utility – the BCD contains that information for me. And then it's the boot manager that's able to read that information. If I do have more than one option or choice, boot manager might actually display a menu on my screen and giving me the option to select which operating system I want to boot to.

Now initially boot manager is hidden. And it's found in a special partition about 100 megabytes to 300 megabytes in size. And it's hidden there, so it gets to be protected by little bit of obscurity because it's so critical to the rest of the boot process. That's especially true if we're talking about a biospace boot system. It's even more difficult to view if you're using a UEFI boot system. Nevertheless the bootmgr's job is to locate winload. And, once we find winload, we're able to locate the operating system kernel. So this gives you an idea of where those boot components live on Windows 10. Now I want to talk a little bit further about the specific differences between BIOS and UEFI. Now one of the things to be aware of is that Windows 10 supports both of these firmware environments. And you gain benefits by using UEFI. You see BIOS is a very common traditional firmware environment. It's older though. It's only 16 bits in size and that limits what can actually be done inside of the BIOS. It's also slow and, well, legacy.

UEFI, on the other hand, gives us several different benefits that improve our Windows 10 experience. One of the things it does for us is it provides an early level environment where we can run antimalware, where we can actually validate the actual boot environments to ensure that they have not been tampered with or changed or altered in some way. And so we can actually use the UEFI environment as kind of an early operating system environment to apply protection and security for our Windows 10 boot. It also supports things like GPT boots. And it's also extensible so that vendors can add additional software. I actually had a UEFI system with a copy of Linux built into it. And I could browse the Web even before I was able to boot into Windows 10. UEFI has a lot of capability and where Microsoft actually leverages it is the fact that it provides some security integration with your TPM chip. And combined, you have a much more secured environment when you're booting to Windows 10. If some sort of rootkit comes along and tries to change your boot manager and inject some bad code, well, UEFI with the help of some Windows 10 security features could detect that and respond to that and prevent that from happening in the first place. And so UEFI is a superior firmware system. And, when you're acquiring new systems for Windows 10, be sure you look into the UEFI and UEFI features that are available.

Back to top

1.

So now let's talk about BCD. BCD stands for Boot Configuration Data. And this is the container or registry hive that boot manager uses to locate the actual operating system for boot. So where is Windows 10? Well, it reads BCD to find out the location of Windows 10. Find out what directory it's in, and what partition it's located in. In addition to knowing where Windows 10 or Windows 7 or Windows 8 is located, you can also set all to dual boot with legacy Windows systems. There might be elements or entries, as they call them, inside the BCD to dual boot to previous operating systems – probably not very common. What I do is I actually have native VHD boot on my system. So I dual boot between Windows 10 and a VHD-based boot of Windows 8. And so all of that information is stored inside the BCD. And, during boot time, the boot manager reads the BCD and I'm displayed a menu. And so I can choose between Windows 10 or Windows 8 VHD boot.

Now there are other things stored in the BCD, some of them relate to, like, hibernation or a memory tester. Or, if I need to do some sort of recovery, I also have available to me the WinRE. You can edit the contents of the BCD and make changes to it to support maybe a dual boot situation or native VHD boot or even read what other additional entries are in there that relate to things like WinRE using a handful boot configuration tools. Now here is a look at some of the tools that can help me govern that initial boot environment or that initialization period called the boot process. As we talked about earlier, the BCD contains a lot of Boot Configuration Data, but it needs to be stored in my system partition. So I can use this tool right here, DiskPart, to actually govern or create those partitions where I'm going to store boot manager and where I'm going to store the BCD. We can also use DiskPart to create a VHD. So I can set it up for native VHD boot or maybe create some additional partitions. I can use DiskPart for just configuring any disk for that matter – so command line tool for formatting and preparing disks.

Now the other tool I want to bring to your attention includes BCDboot. And BCDboot is helpful because one of the things it did for me is it can actually help me quickly configure a new system especially for dual boot. Where I use BCDboot the most is when I'm setting up a native VHD boot situation where I have an image in VHD and I have another installation located on the C drive and I want to create a dual boot between them. One example of this is say I wanted to experiment or explore the new version of Windows Server and dual boot with that on my Windows 10 system. While, I can put Windows Server inside of a VHD, I can use DiskPart to do that. And then I can mount it and use BCDboot to set up the actual boot environment. This ensures that the boot configuration data and the files themselves are up to date so that they can support booting to the new operating system. So it can be a really handy command in those situations. This brings us to our third and final boot configuration tool and that's BCDEdit. And this tool is kind of the Swiss Army knife tool. And what I mean by that is it can actually perform a lot of important task. BCDboot is helpful because it helps speed up the process, but you could skip that if you wanted to and do all of the necessary commands manually with BCDEdit. BCDEdit also lets you explore your boot environment in greater detail and allows you to change all kinds of entries inside the BCD itself. So you can actually create brand new boot entries. You can actually change what is displayed. You can change the time-out and a variety of other settings that relate to the boot process.

Back to top

1.

Now I've been talking a little bit about native VHD boot. So let's get into the details of what exactly it is and how we would set it up using boot configuration tools. And this is supported with Windows 10. So I can set up a VHD, put Windows 10 in it, and I can boot to it. So maybe you're interested in exploring Windows 10, but you've already got an installation of Windows 7 or Windows 8 – you don't want to disrupt. Well, this might be something of interest to you because you could set up a dual boot situation with native VHD boot. First off, let's talk about how native VHD boot works. We already know that we can actually install Windows 10 to my disk. So, like a traditional type of installation, it goes right to the C drive stored in a partition. Thing is that installation becomes coupled with that disk, and it follows wherever that disk goes. And that disk doesn't usually go very many places because it's a physical disk, right. It's not something you're going to unplug and move it around. Well, VHD is a file-based disk. And so you can put your installation inside of the VHD file. Now, in the past, we would use that for the purpose of virtual machines. So we would install Windows 10 or whatever operating system into our VHD. We would have some sort of Microsoft-based virtualization platform that could read, mount, and use those VHD files in a virtual environment. And so we would have our virtual machine running in a separate container or partition on the system sharing the hardware with the operating system that's on the C drive.

Alternatively, we can also do native VHD boot – no virtualization required. You can boot to a VHD file without virtualization and that's important. So let me say that again. You can boot to a VHD file without virtualization, without Hyper-V. And the way that you do that is you actually install Windows 10 into that VHD and then it's the boot manager here, bootmgr, that can actually read that VHD file and boot to it as an alternative to booting to a partition. Now there are some limitations to the way VHD boot works. So let's talk about those limitations for a moment. First off, native VHD boot requires that you have at least two partitions. So you have that 300 or 100 megabyte system partition where boot manager lives. And then you have, of course, at least one partition that's been formatted and prepared by having OS already on it. But it doesn't require that. In fact, I've mentioned a few times that VHD boot is useful for dual boot, but it doesn't have to be. It can be your primary boot, so that's important to remember as well.

The other thing to know about VHD boot is it doesn't support hibernation. It doesn't support good, old-fashioned, dynamic disks. And it really doesn't work well with nesting – so setting up a VHD inside of a VHD inside of a VHD. Now there are a couple of recommendations I want to highlight to you and that includes the fact that it's recommended that you use fixed-size VHDs. Now that simply means that the VHD doesn't actually dynamically expand on-demand. Instead, it's already carved up in terms of its size. So, if it's a, you know, a 60-gigabyte partition, it's taking up 60 gigabytes of physical disk space as opposed to a differencing or a dynamic disk – it might actually be a 60-gigabyte file, but only taking up 20 gigabytes. Now the reason why you want a fix size is because that ensures that fragmentation is less likely to occur. And that can ultimately affect performance, alright. So only use those dynamic disks for testing purposes. And so that gives you an idea of some important things in regards to VHD and some things to watch out for.

Back to top

1.

Now, if you're looking to automate the installation of Windows 10 doing traditional deployment or you're looking to use the Application Compatibility Toolkit or the new provisioning and configuration designer tool, well, then the ADK is what you actually need. The ADK provides a suite of tools for several different purposes that help you service and install Windows 10. What exactly is the ADK? Well, the ADK is the Windows Assessment and Deployment Kit. It's actually a free download. And it's part of the overall deployment solution. It includes important things like an assessment and a performance analyzer. It includes the Application Compatibility Toolkit. It also includes this guy right here – WICD. This is the new Windows Imaging and Configuration Designer for provisioning packages. If you need to create an answer file in the traditional sense, you could use the Windows System Image Manager. If you want to capture the user state and migrate user profiles, you could use the User State Migration Tool. If you want to service images, you can use DISM. And of course, there are some other tools as well that are part of the ADK. Notice the ADK is a foundational set of tools used for a variety of different purposes that could be troubleshooting, that could be deployment, that could be provisioning, and so forth. It sits down here as a kind of a baseline or foundation maybe for the other type of tools that can sit on top of it. In fact, the ADK is required if you're using the MDT. It's required if you want to actually set up and automate the actual Zero-Touch or System Center Configuration Manager deployment. It plays a pivotal role in supplying key components for these other solutions as well.

[The Windows Assessment and Deployment Kit contains the following tools: Application Compatibility Toolkit, Deployment Tools, Windows Preinstallation Environment, User State Migration Tool, Volume Activation Management Tool, Windows Performance Toolkit, Windows Assessment Services, and Microsoft SQL Server 2012 Express.]

Now, when you download the ADK, you're given the option to install several different components. So you got a list here. And you can choose which items in the ADK you want to include. And so you could select, for instance, the Windows System Image Manager that lets you build an answer file. And this answer file can be used for a variety of different stages of servicing or installing Windows 10. So, for instance, Setup.exe can read and parse an answer file. And you can automate the configuration of your disks and automate the OOBE process and specialization process. But Sysprep can also read an answer file. DISM can also read an answer file. Windows PE can also read an answer file. So you can basically use the ADK to drop this guy on your machine and then create answer files for a variety of different features or different functions. Now, in addition to that, you can also use the ADK to give you the assessment and performance analysis tools. This allows you to evaluate your systems, measure their performance, and troubleshoot those systems. You can also access the WinPE tools. And this is helpful if you want to create your own, kind of, custom Windows PE environment. Remember PE is the preinstallation environment. And what that does for me is that it gives me, kind of, a mini Windows environment so that I'm launching, you know, setup from in there or I'm launching servicing tools and maintenance tools, maybe even automating it through the help of an answer file and some other scripts that it executes and it reads. So the Windows PE tools are available so that I can set up a custom environment for whatever function that I need.

And then lastly, we have this guy right here. And this guy is new. This is the Windows Imaging and Configuration Designer. And what it does for me is it actually helps me create provisioning packages. And provisioning packages are pretty sweet because instead of having to reimage a system, I can actually apply configuration settings to a system. So it's, kind of, like an answer file but on steroids or like Group Policy settings but in an XML kind of configuration format. It's not related to Group Policy. And it's much more than the traditional answer file. Those are just analogies. The idea with the provisioning package though is I can create very specific settings – things like VPN profiles, things like certificates so that I need to install Wi-Fi profiles, enrollment settings for MDM, and so forth. This is really a great tool when I have BYOD scenarios or I have a lot of mobile devices that I need to configure and make them enterprise ready. So this allows me to create package files that transform a device so that it's corporate ready. The ADK includes this tool along with all of these other tools and more tools so that I can use it for troubleshooting, compatibility testing, performance analysis, and – of course – servicing the images and preparing for deployment.

Back to top

1.

Now one of things the ADK lets me do is create my own custom Windows PE environment. So the next thing we're going to look into is how to create Windows PE. Now, of course, the first thing we want to address is what exactly is Windows PE. Well, Windows PE is the Windows Preinstallation Environment. And it's important to remember that it's not full Windows but a mini Windows that's running so that I can perform various tasks in, kind of, an offline mode. So it's not running off of disk. It's instead creating what is called a RAM disk in memory. So it's entirely running in memory for me. And, from this RAM disk or this memory location, I can – in Windows PE – execute a variety of different tasks that relate to either deployment or to servicing the image. So I can use it to capture and create an image by using the tool called DISM. I can use it to help me perform user profile migrations. I can use it for installation and deployment tasks, like applying a WIM file. Or I can use it to provide recovery environment for my tool. So, if I need to do a memory tester or I need to actually examine potential problem because the system won't boot any longer, I can boot into Windows PE and run a handful of recovery tools against that system to try to diagnose or fix my problem. So Windows PE is really an IT professional's best friend when it comes to doing that kind of low-level servicing and maintenance or providing an environment where we can run setup and perform installations.

Now let's look at the features that support Windows PE functions. Of course, we need to have a file system, so we have NTFS file system support. We also have built-in networking support. Now, when you build your own custom Windows PE, here is a tip. If it's not working on your systems, then one of the common reasons is it doesn't have the driver that it needs in order to initiate the network or perhaps even initiate the disks and the controllers that are found in that system. So you want to make sure your Windows PE installation has those core-level drivers. Once it has those drivers though, you can of course do all kinds of great things with Windows PE. For instance, you can even run Windows PowerShell commands. I love that about Windows PE – the PowerShell support that's included in there.

Now, if you're not using Windows PE to execute PowerShell commands, you can actually customize it to leave that out. So you can make Windows PE basically a really small image or a much larger image. Now the larger your Windows PE image, the more time it takes to boot. So you have to keep that in mind as well. But, you know, the options are yours. You download the ADK, and you can create and customize Windows PE to your heart's content. And it can include whatever tools you needed to do. It can be a very simple, single function environment. Or you can even put some graphical components in it. It can even run HTML applications in it if you wanted to. It can read answer files. And that's where you can automate how Windows PE boots and what functions it has. And it can boot from multiple media types. And this includes your good old-fashioned UFD or USB stick. But you can also pull it down from the network. And so you can actually have Windows PE sitting on a Windows Deployment Server. And, when your machine boots up using PXE, WDS can deliver a Windows PE environment. And we often do that if we're going to automate the installation with Deployment Server, like an MDT server or a System Center-based installation. So we'll use WDS to help automate that process. Windows PE supports all of these different features.

[A bootable WinPE environment is needed in order to issue command-line commands against a reference computer or to initiate installation outside of setup.exe. You can create a WinPE environment by following the steps below: 1. Open Deployment and Imaging Tools Environment (this is the ADK CMD prompt). 2. Create PE files (example: copype amd64 C:\mywinpe). 3. Add drivers or packages (optionally, use DISM command). 4. Add answer file or custom scripts (optionally, store unattend.xml at root of media). 5. Install PE files to media (example: MakeWinPEMedia /UFD C:\mywinpe G:).]

So now we're talking about the hundred thousand dollar question. Or is it a million dollars? I don't know. How do I create my own Windows PE? Well, we've already kind of alluded to this a little bit. You're going to use the ADK to do that – going to download the ADK and provide or use, I should say, what it provides in order to create your own custom Windows PE. Now the procedures are listed here for you on the screen. And really they are pretty simple. It's a matter really...at least the way I do it is. I have my TechNet article up in my guide and then on my other screen, I'm doing this. And a lot of times I like to use virtual machines for this. And I can even reuse it outside of a virtual machine, but I often start in there. Now couple of key tools that you're going to be using when building your Windows PE environment.

Inside of the ADK is a batch file that's already designed for you. It's called Windows Copype. And what it does is it actually will build the initial folder structure with the initial files that you need. When you run Copype, you have to indicate what architecture that you're building in Windows PE for – 64 bit or you're doing it for 32 bit. Now it says AMD 64. Don't worry about that. AMD 64 works on Intel or AMD, doesn't matter. The point is that's the actual indicator that we're dealing with a 64-bit architecture as opposed to i386, you know, the x86 meaning 32 bit. Now, after you do that, the next thing you want to be aware of is you're actually going to be using DISM there. And DISM is going to be the key tool to kind of customizing and setting up Windows PE with variety of different packages. So, if you want to include PowerShell support or HTML application support or other types of components, you can draw packages into your Windows PE. But it's DISM that allows you to do that.

Once you're finished customizing it, then the last thing you're going to do down here is you're going to use MakeWinPEMedia. And then that will generate for you your Windows PE environment on to some bootable media. And that can be a flash drive if you have a flash drive present. Or you can pipe it out to an ISO file. And then, of course, you can turn around and use that in other places as well. So you could actually take the content of this, go to your WDS server, and have WDS deliver the actual Windows PE image that way. All of this is stored inside of a file called Boot.wim. You might recall that Boot.wim contains Windows PE. So what you're building here is a Boot.wim file – a custom Boot.wim file that you can then turn around and use for whatever purpose. So you might be putting tools in there for troubleshooting and servicing and recovery. Or you might be putting tools in there that relate to running a light-touch installation with the custom application. Or you might be putting just some basic tools in there for the purpose of capturing an image or servicing an image. Whatever the purpose or function is, these are the basic steps to get your Windows PE image created.

Back to top

1.

Let's talk now about creating an answer file. Before we do that, we need to answer the question, what exactly is an answer file? Well, an answer file provides instructions or answers for when we are needing to do an installation. So it helps us automate setup. But it can actually do a lot more than that. It can also be used by Windows PE. Windows PE can read it. DISM can actually read it. Sysprep can actually read it. Inside an answer file are these configuration passes. And different components that belong to the installation category can read an answer file and be automated and consume the instructions there, like with DISM – for instance – you can write inside the answer file the location of a batch of drivers that needs to use. Or, with Sysprep, you can provide instructions on how you wanted to prepare the system for installation, like – for instance – you can tell it to remember the Plug and Play devices it detected as a part of the procedure of preparing the system to become captured in an image, right, assuming you're familiar with the way Sysprep works and you can use an answer file to help automate that. Now one of the key things to know about it is it's XML based. So there is a specific schema that Microsoft developed few years ago. And we're still using that schema to build basic answer files. The tool we use is called the Windows System Image Manager. Now where do you get the Windows System Image Manager? You might remember where it's the ADK, that's right – the Assessment and Deployment Kit. So, when you download it, one of the tools that comes inside the ADK is the Windows System Image Manager or the WinSIM. And that's what I can use to create and edit answer files.

Now, to understand how an answer file works, we're going to take a moment and look at these configuration passes in a little bit more detail. Now the answer file is constructed in configuration passes. So, when you open up WinSIM, you'll see the different configuration passes, they are listed in a brand-new answer file. And then what you do is you populate it depending, of course, on what you're trying to do. So Windows PE, for instance – its job is to actually read the actual portion or configuration pass. So any instructions that you want Windows PE to read, you're going to put them in that part of the answer file. Windows Setup can actually read Windows PE, but it can also parse and read information in an offline servicing, the specialize pass, and then the OOBE configuration pass. And these are several phases that occur during a basic installation. You start with Windows PE, setup executes, we create the disks, we start copying the files, right. Then the specialize pass binds unique settings for that installation to the device. And OOBE is that out-of-box experience. So that's really, kind of, your whole installation procedure that was various phases listed there. And you can automate those with an answer file by supplying answers to those sections of your answer file.

Now Sysprep down here can also be used to read an answer file. So there is a generalize configuration pass for generalizing the system – kind of neutralizing it, preparing it for actual image capture. But then, if you're building an image – a custom image – so you build a reference computer. If you're familiar with the imaging process, you know, you build a reference computer. And then you make edits and changes to that. Well, then you might want to test those edits and changes before you turn it into a WIM file. So there are a couple of other configuration passes that support Sysprep. Inside of WinSIM, when you open it up to create an answer file, you'll see these configuration passes, you'll see Windows PE, you'll see the offline servicing pass, you'll see the specialize pass, the generalize pass. They relate to these three different components. And they relate to these different executables really reading and using the answer file. So, if you want to automate Windows Setup, be aware of the fact that these are the four configuration passes that you would edit inside your answer file.

[You can use an answer file to customize setup. To do this, you will need to name it autounattend.xml and store it at the root of the install media or on a flash drive. You can also call up the file with the following command: /unattend:[filepath].]

Alright, so an answer file – as we've learned – is an XML file. How do I use the answer file now that I've built it? For setup, you can use it by simply calling it with the /unattend switch right there. Alternatively, you can name the XML file autounattend.xml. You name it that specific name. And what you're doing then is you're instructing setup to use that answer file because setup already looks for that file by that name. So it's predisposed to hunt around and look around for autounattend.xml. And it looks in several places. It looks at the root of the C drive. It looks at the root of the removable media. It looks in a couple of other places in the Windows directory in search for that file. Really, if you name it autounattend.xml and make sure it's available at the root of your boot media or your installation media, you will find it and you don't actually have to use any switches or reference it at all. Otherwise, if you're using an answer file for Sysprep or WinPE, they also have their own switches. For Windows PE, I should clarify. Windows PE actually has its own bootstrap process and its own boot files it uses at execution – so Startnet.cmd, for instance. So what I would do is I would name the answer file and I would put it at the root of the Windows PE media in the appropriate place for it to automatically find it. And then Sysprep has a /unattend switch that I can use.

Back to top

1.

So the next thing I want to talk to you about is the MDT as it relates, of course, to Windows 10. Now some of you might have been using the MDT before. You're familiar with how it works. MDT stands for the Microsoft Deployment Toolkit. And I love the MDT. I've used it out for years. It has been around since – you know, roughly around – Windows Vista period of time. And what the MDT does for me is it helps me automate the creation of my images, the maintenance of my images, and then the deployment of my images. Now, if I'm doing a traditional deployment and I want the level of automation that the MDT supplies, a minor upgrade and it will support Windows 10. Now, to give you a perspective of where the MDT fits in the overall picture of the installation options, you can see here that the MDT supplies for me what are called Lite-Touch installs. So what that simply means is I can build the MDT to support some intervention with an IT professional where they initialize the install, maybe they answer a series of questions in like a web application, and then the install takes off. But I can actually automate that even further. So there is very little actual interaction. So it can be a real lite-inputted install. And I can customize the installation with the help of the MDT. And the MDT is relying on these components down here below including this guy right here – the Microsoft's Windows ADK. So I like this diagram because it shows me that the MDT participates but is also dependent on the other installation components.

Now here's an overview of the features that the MDT supplies for me. So it's a centralized store, right. So it's going to contain for me a lot of key things that are needed or required at the time of an install. So, if I am doing a traditional deployment, the MDT can support the operating system Windows 10, Windows 7, Windows 8, XP. But it can also support for me other sources. So I can have it store applications, I can have it store drivers, and I can have it store other kinds of packages and updates. And what I do is I kind of pull all of those ingredients together and automate the use of those ingredients through what are called task sequences. A task sequence is going to vary depending on if I'm doing an upgrade or I'm doing a clean installation or I'm doing some sort of image-capturing process. Whatever I'm actually trying to accomplish, I build a variety of task sequences. And those task sequences then rely on that centralized store of information – those centralized WIM files, you know, driver files, and application installation instructions.

And so I can build-in out...here's where I would build out my task sequences here. And that makes the MDT immensely powerful. It allows me to upgrade Windows 10 in an automated fashion. So, if I decide that I want to take advantage of the enhanced upgrade that Windows 10 provides – the improvements in that region – I can do that even with the MDT. If I need to do a traditional deployment, the MDT is my friend and helps me automate that procedure. If I need to create a custom image from Windows 10, the MDT has task sequences to support that. So the MDT is I think of...it is, kind of, a factory where I can stock the shelves with all the different pieces that I need and then I can bring them together for a variety of different reasons. And so it's a very powerful solution. And it's free to download, you know. I'm going to need to have the ADK and licensing for the source files and the applications, but the solution itself is free to download and to use for the purposes that I described.

Back to top

1.

So you need to build a custom image for Windows 10. How do you do that? Well, let's talk about creating custom images. Now the first thing we want to ask is how do I create a custom image for Windows deployments? Now many of you have done this procedure before for previous Windows operating systems and in many ways, it has not changed. You have many of the same options. For instance, you can create your image manually, which means you download the tools from the ADK and you use the variety of tools in there to build out your reference computer, turn that reference computer into a custom WIM file, and then you can capture that reference computer using DISM inside of Windows PE. Or that sequence that I just described is automated inside of the MDT. You can also capture images with the help of System Center and WDS. So there is a server-based, more automatic approach to creating your custom image. Nevertheless, both of them are going through the same basic procedures.

Now this slide shows us where all these tools relate to each other. And, as you can see, what we're going to be doing here is using many of them to create our image. Of course we're going to need the ADK. We're going to need those tools to help me manually create the image. If I want to do it automatically through MDT or System Center, then I am still going to need the ADK and a lot of those supporting tools. And this, of course, also includes a need to have my WIM files and my base image and the other supporting know-how to build my custom WIM file so that I can automate my installation of Windows 10 to a whole population of computers. Or maybe I am trying to do this so that I can perform an upgrade from a previous Windows-qualifying operating system like Windows 7 or Windows 8 and I want to upgrade them. Whatever reason and whatever ultimate purpose that I have here, these are the many tools that I am going to use to build my custom image. Now one thing I want to point out is there is a big advantage to this and that is these scores of tools that are here give me a lot of control and lot of options. The downside to this is that there are scores of tools here to learn. Now, if you have been working with these tools in the past, then this is probably no big deal to you. If you're new though, well that's what I am here for. So we're going to walk through these procedures and show you how to build a custom image using the ADK and these included tools.

Now the first thing we want to understand is what kind of image are we trying to create. Are we going to create an image that has everything we need in it, that gets you in sync and all the furniture, and all of that kind of stuff? That's what we might call a thick image. Now the nice thing is we've got all our customizations in this single thick image. The downside is that if I have multiple devices that have different diverse needs then I might not have to create multiple thick images. So another approach is to do the thin image where all I am doing is automating the installation of Windows 10. Applications – well, those are going to be installed through some other means. I am going to use maybe System Center or maybe I have a third-party application distribution system or maybe MDM and I am using Intune to help me. Whatever the case might be, I am going to do be delivering my customizations through some other configuration and application channel separate from the actual installation of the operating system. So that has some key advantages. In that, I am able to maintain a single small image for more diverse systems. The downside is I have to make sure I've got these other channels working and available. And so that might require some additional work or some additional licensing cost.

[The In-Band images are also known as thick images. These contain core applications. Some advantages of the In-Band images include speed and simplicity (at least until the image needs to be updated), single-step deployment, and availability of core applications on first start. Some disadvantages of In-Band images include low flexibility, high storage cost, and potential network cost. The Out-of-Band images are also known as thin images. These contain few core applications. Some advantages of the Out-of-Band images include high flexibility and low storage cost. Some disadvantages of the Out-of-Band images include complex post-deployment configuration, non availability of core applications on first start, and required systems-management infrastructure. The Combined images are also known as hybrid images. These are a mixture of thin and thick images. They can create thick images from thin images. An image installs apps on the first run as a post-installation task. Some advantages of the Combined images include more flexibility as compared to the thick images, less testing, and lower storage cost. Some disadvantages of the Combined images include long installation time and potential network costs.]

Then there is the hybrid approach. And this is the one kind of in-between thick and thin. With the hybrid approach, I can opt to do an installation on the operating system with a few applications that are kind of core to everybody. And then any additional customizations can come through some configuration or MDM channels or Group Policy channels or a third-party solution as well. So that's kind of the in-between option. Now, whichever one I am going to choose, it doesn't matter, I am going to go through the same set of procedures to build my image for my deployment or my upgrade. The amount of customization I need to do to that image, well that's where these come in. I am going to do a lot of customizations typically if it's a thick image approach. I am going to do fewer customizations if it's going to be a thin image because those customizations are coming from somewhere else.

So now let's look at the process to create the custom image. And this is a set of steps that many of you're probably familiar with and you may have done a lot of this when building images for Windows 7 or Windows Vista. And the steps and procedures haven't changed. Now, if you're new to this, don't worry, I am going to walk through the various stages of creating the custom image one at a time. Now the first thing we need to do is we need to prepare our technician computer, and that's really kind of assembling the pieces, right. So we're going to get our source files, our application source files, our driver files – whatever source files that we need. Perhaps it also means building out our infrastructure – so setting up MDT, then stalking the different parts of the MDT deployment share with the different source files. So we're going to gather those up and we're going to build out our technician computer with the appropriate software. And then what we're going to do is we're going to use the tools on the technician computer to prepare to create my reference computer. Now remember, the reference computer with imaging is going to be basically the clone that we're going to duplicate. And so we're going to want to automate as much as possible creating my reference computer and it's going to become my thick image, my thin image, or my hybrid image.

[The syntax to generalize and prepare the system for image capture is as follows: SYSPREP /generalize The syntax to capture image from reference computer from DISM is as follows: DISM /Capture-Image/ImageFile: v: \custom.wim/CaptureDir:C:\ /Name:Windows]

So I can include and automate the installation of the reference computer using an answer file. I am also going to need Windows PE to use that as my staging ground to run several tasks against the reference computer – whether that's installing it, whether that's capturing the image. So I am anticipating a need for Windows PE. So I am going to build out my WinPE media. So I've done some preparation tasks, I've authored some key pieces. The next thing I am going to do is actually install the reference computer. And this is why I am going to put Windows 10 on it and then I am going to put my customizations on it and I might need to do some manual tasks there. But I am preparing it to actually become my thin image or thick image or whatever image strategy that I am aiming for. Now that includes customization, so I might also include installing applications. Once I've performed my customizations and I've got my reference computer at a stage where I want to duplicate it, I've got to generalize it. So this is where I am going to run sysprep /generalize. And this is not something that's part of the ADK. Sysprep is built into the Windows directory. And so it's local. So I can find it there on the reference computer. And this is going to prepare it to be duplicated across multiple machines. By the way, Sysprep also can read an answer file. So, if there are additional steps I want Sysprep to perform during the audit stage or generalize stage or the specialize stage, then I can actually write that into an answer file and reference that with my Sysprep switches/unattend and then include/generalize.

Now, after I've done all of that, I am going to boot in to Windows PE and then I am going to capture my image. I am going to use DISM to do that. Of course, I can automate this process with the help of MDT and WDS and System Center, but this is the actual syntax I would use if I was going to do it manually from Windows PE. Then final step here is to actually apply it to my target computer. So I've got my population of machines. I am going to deploy my custom image. And I can do that either automatically or I can do it manually depending again on my strategy. But this overall is the accumulative set of steps that I need to walk through in order to actually get to this stage and getting Windows 10 out there on all of my computers.

Back to top

1.

Now here's a quick look at the basic steps to get your reference computer ready to go including the steps in regards to customization. So you're going to install the operating system. You're going to customize it – either using the answer file or performing other types of tasks on the machine, installing applications, and maybe applying scripts and so forth, install updates and patches. Once you've got your Windows 10 image looking the way you want it for duplication, the final step is to run Sysprep against it. And Sysprep is going to generalize the system and prepare for capturing. Now generalization, if you're not familiar with that, what that does for us is it makes the system able to be duplicated. There are settings that are unique to each installation and don't duplicate very well. So I am creating an installation image here, but I want to be duplicated. So Sysprep assists me by preparing that system and making it generic so that I can duplicate it across the population of devices. And so I am going to run Sysprep. Now Sysprep is not part of the ADK. It's actually built into Windows. So you'll find it in a Sysprep folder right there in the Windows directory of every installation of Windows 10. So you'll find it available to you on the reference computer. No additional download is required. Okay,

[The steps to prepare the reference computer before capturing a custom image are as follows: 1. Install the OS with an answer file. 2. Install applications. 3. Customize settings. 4. Install updates. 5. Run SYSPREP/generalize.]

so you've built your reference computer. The next big question is how do I capture the reference computer. Capture the reference computer, tackle it, wrestle it to the ground, and then turn it into a WIM file. Well, you don't have to actually wrestle it to the ground. It's much easier than that. To capture the reference computer, what you're going to do is boot into Windows PE. That's going to give you that offline environment where you can run the DISM command and use the capture image switch. And that is the procedure actually that takes the installation that's in the reference computer on disk and turns it into a WIM file. Now this also works of course with virtual machines. And I actually like to build my reference computers in virtual machines and then use this procedure to turn that virtual machine into a WIM file that I can use on physical machines. And that's certainly doable as well. Alternatively, you can actually create your custom WIM file using the task sequence in MDT. There is a capture task sequence that you can configure and that will just automate the process a little bit for you. So you're not having to type all that out.

Back to top

1.

Okay, so you've built your actual custom image. You're wanting to use it. You have used it. Now you need to make a change to it. Maybe there is a driver missing from it; maybe there is a new update you want to add to it; maybe a new application perhaps. So what are the things that you can do to service the image? Well, we can go through that whole capture and...you know, the whole deployment and then capture process, but that's very old school. One of the advantages to using a WIM file, remember, is the fact that we can actually mount it and service it offline. And so I love that about the way that the WIM file works. So let's talk about servicing an image. The way you service an image is use DISM, right. But what DISM does for me is it allows me to do all kinds of things. It's really kind of the Swiss Army knife of deployment tools. So it allows me to add drivers; it allows me to have packages; it allows me to sideload applications. So I can insert apps into there. And it allows me to customize Windows. So it allows me to perform a variety of different tasks – to do that without having to go through that really lengthy image deployment and capturing process. So DISM is your friend. Using DISM to service an image will save you a lot of time. And so become good at using DISM. Spend some time practicing DISM because DISM can be used for not just these four different things, you can also use it to upgrade an edition of Windows 10 to a new edition. So, if you've got Windows 10 Pro, you can actually use DISM to upgrade it to Windows 10 Enterprise. And so there are a lot of online and offline functions that DISM provides. So get good at using DISM.

Back to top

1.

So you've gone through all of the hard work, actually creating custom image for Windows 10 and you want to then deploy it. So what are the steps and procedures to deploying your custom image? That's what we're going to talk about next. Now there are several deployment methods available to you. So you've got a custom image and you want to deploy it. You can do that with DISM, you can do that with Setup.exe, or you can do it automatically with the deployment server options that are available to you. And this includes a PXE-based server, Windows Deployment Server. It includes MDT – Microsoft Deployment Toolkit for Lite-Touch deployments. It also includes System Center Configuration Manager for Zero-Touch deployments if you have System Center. You've got choices here. That's what this is about – choices.

So let's talk about the tools that are associated with those deployment choices. Now what is common in all of these scenarios is setup and then we also have the ADK. So small business, mid-sized business, and enterprise business can take advantage of that, you know, set of tools that are in the ADK for creating my custom image and then deploying that image. In addition to that, I have other tools that are inside the ADK that I can leverage – like for instance there is the WICD tool. Now this guy here is important because it allows me to create the new provisioning packages – not so much a part of a deployment strategy as a way to be included in a deployment for actually configuring my devices. And so that's actually pretty exciting. I really like that about the new provisioning tools. And that's new to Windows 10. That's not something that is supported with Windows 8 or Windows 7 at this time.

Now further I go to the right here, the additional tools that I have support, you know, enhanced or additional levels of automation. So there is a corresponding reality to this. The more devices I have – which puts me in this enterprise category over here – then there is a greater need to have automation. So I am going to leverage the ADK significantly, but I am going to use it in the context of the MDT – the Microsoft Deployment Toolkit – or use it in the context of Configuration Manager or System Center. So these become important enhancements to even just the basic tools like the ADK so that I can do more mass deployments and save my organization a lot of time. This means what I am thinking about here is I am thinking about my IT time. I am thinking about the time it takes for my pros to drive to that remote office and do a manual deployment. And I don't want my IT technicians nor, you know, me to have to do a lot of driving or a lot of kind of manual labor or babysitting a lot of clicking. And so the further to the right I go, I have more automation options available to me and I just have to decide which strategy is going to be best for me. It's not necessarily pertaining to the size of the organization either. I might be a smaller organization with System Center available, I might have a third party imaging solution that I am using, or I might want a simpler approach so that I am going to rely instead primarily on using provisioning packages or an upgrade. Whatever the case may be, one of the things I have to decide is what deployment strategy is right for me.

So, if you want to apply the image manually, you can do that with DISM. So all it takes is really just knowing this syntax right here – DISM /Apply-Image – and then reference your custom image with that. And then you can indicate where you're going to drop it. That's the apply directory piece right there. And then, as an alternative, I can use setup. So here's a little trick. One of the things I can do is I can take my custom.wim file, rename it install.wim, and replace the original install.wim with my renamed WIM file. And so basically, it's a swap out. And so I can get setup to automatically apply my custom WIM file. So that's a handy trick. Of course that's manual. And the benefits of this is I am able to actually perform this installation rather quickly without a lot of overhead that might be required if I needed to add automation to it. But then I might need to add automation to it. And, if I need to add automation to it, that's when I am going to resort to asking for help with a server-based deployment. Now my server-based deployment...I've got some choices here as well. Microsoft supports WDS. So I can import my actual custom image there. I can import my custom image into MDT and System Center. Whatever strategy that I am electing to use – I might even have a third-party option – I can make my custom image available to them. And then this is advantageous in that it helps me deploy – in mass – to large numbers of machines my Windows 10 image along with all of its customizations.

[The syntax to apply an image with DISM is as follows: DISM /Apply-Image /ImageFile:V:\custom.wim/Index:1 /ApplyDir:C:\]

Back to top

1.

Alright, so the next thing I want to talk to you about is Windows To Go. Now we're not talking about buying Windows from a drive-through. "Can I get one Windows To Go?" No. We're talking about actually installing Windows to a USB stick. Let's look at the details behind Windows To Go. Now Windows To Go is another installation source. We've talked about installing Windows traditionally to our hard drives. We've talked about installing them to VHD. But I also have available to me the option to install it to a USB stick. Now we're not talking here about installing a custom image inside of a USB stick so that I can deploy from it. I can do that, but that's not Windows To Go. Windows To Go is actually running Windows from the USB stick. And that's a different animal altogether.

So how exactly does Windows To Go work? Well, you need to have a supported USB stick and it needs to at least be 32 gigabytes in size. And you're going to want to have one that supports pretty good I/O. So it's best to find one that certified for Windows To Go. Additionally, you're going to need to have host systems that actually support the minimum requirements for Windows 10, which happens to be the same as Windows 8 and Windows 7 and even have support for Windows Vista. So, if you've got somebody who has a system at home that meets these minimum hardware requirements, then here is a possible option or scenario for you. You can issue to them a USB stick that meets those qualifying requirements, that has Windows 10 on it, and they can actually run Windows from that USB stick on their own device. So Windows To Go works really well for organizations who have temporary workers or contractors or even remote users, telecommuters and such where you don't want to issue a device to them, but you still want to issue them a configured image. And, as an alternative or as an option, you can do that through Windows To Go.

Now there are some operational differences when you're running Windows 10 off of the USB stick. For instance, we've got limitations in terms of hibernation and sleep states. Those are disabled. The internal disks are offline by default. You do have Bitlocker support, okay. There is encryption so you can protect your image that's running on it, but it's not going to be integrated with TPM. So it's going to be basically a password protected in terms of encryption. You also don't have your recovery tool and some of the integration, like push button reset there, is not available. So that's some of the limitations behind it. Nevertheless, despite these limitations, Windows To Go becomes a valuable asset or option when you have situations that require users or customers or employees having a Windows 10 image tailored for their job and enterprise compliant and yet we don't have the hardware to issue them. Maybe they already have an existing laptop or a device that would support it. So we can give them the image off of a USB stick and have them run Windows 10 from the USB stick.

Back to top

1.

Here's the situation. You want to create a new provisioning package for runtime, and you want to configure a new home page from Microsoft Edge using this package. Think about that with me for a moment. How do you do that? What are the procedures and the steps involved in creating a runtime provisioning package with that configuration. I'm going to give you a couple of minutes to think about it. Feel free to pause the recording and resume it when you're ready.

Okay, let's build a runtime provisioning package. First place I'm going to go is I'm going to Start and open up the Windows Imaging and Configuration Designer. I've already downloaded this and installed it. And you might remember that's done by installing the ADK. Give this a second to load up. I've got a UAC prompt. We'll say Yes to that. All right, so we're going to create a new provisioning package by selecting New provisioning package right here under the Create column. There it is. I'm going to call this Edge Homepage – how is that? And then, of course, I can pick a different location for the project folder. Leave it. Set to common to all Windows desktop editions. Of course, we can choose based on what targeting installation or what installation we want to target there. So I'm going to choose Next. I'm going to click Finish to that. So that's the basic procedure to create a new provisioning package project. Now, to edit this, I'm going to go under Runtime settings then we need to find MicrosoftEdge which is under Policies. Here's MicrosoftEdge. There we are, and then I'm going to choose HomePageURL, and this is where you can put in the home page – whatever that's going to be, okay. And then, once we're finished with this, then we can actually export this. So those are the basic steps and procedures for creating a runtime package that sets the home page for Microsoft Edge.

[The presenter double-clicks the Windows Imaging and Configuration Designer icon on his desktop. As a result, a User Account Control dialog box is displayed. This dialog box includes the following text: "Do you want to allow this app to make changes to your PC?" The dialog box also includes two buttons. The two buttons are Yes and No. The presenter clicks the Yes button. As a result, the Windows Imaging and Configuration Designer window is displayed. This window includes a tabbed page. This tabbed page is titled "Start page." The tabbed page includes multiple clickable options, some of which include New provisioning package, New Windows Image customization, and Open. The presenter clicks the New provisioning package option. As a result, the New project wizard is displayed. This wizard includes three text fields and two buttons. The first text field is "Name." The second text field is "Project folder." The third text field is "Description." The two buttons are Browse and Next. The presenter types "Edge Homepage" in the Name text field and clicks the Next button. As a result, the next page of the wizard is displayed. It includes the text, "Choose which settings to view and configure." The text is followed by four radio buttons. The four radio buttons are "Common to all Windows editions," "Common to all Windows desktop editions," "Common to all Windows mobile editions," and "Windows 10 IoT Core." The presenter selects the "Common to all Windows desktop editions" radio button and clicks the Next button. As a result, the next page of the wizard is displayed. This page includes the "Import a provisioning package (optional)" text field. Next to this text field is a Browse button. This page also includes a Finish button. The presenter clicks the Finish button. As a result, the Windows Imaging and Configuration Designer window now includes another tabbed page. This tabbed page is titled "Edge Homepage." The Windows Imaging and Configuration Designer window also includes the Export button. The "Edge Homepage" tabbed page is divided into three parts. The first part is titled Available customizations. The second part is blank. The third part is titled Selected customizations, and it does not contain anything. The Available customizations part includes a Search text field and two expandable nodes. The two expandable nodes are Deployment assets and Runtime settings. The presenter expands the Runtime settings node. The Runtime settings node includes multiple expandable subnodes. Some of the subnodes are Accounts, Browser, Folders, Maps, Policies, and Start. The presenter expands the Policies subnode that further includes multiple expandable subnodes, some of which include Authentication, Bluetooth, Defender, and MicrosoftEdge. The presenter expands the MicrosoftEdge subnode. The MicrosoftEdge subnode further includes multiple subnodes, some of which include AllowAutofill, AllowPopups, and HomePageURL. The presenter selects the HomePageURL subnode in the first part of the Edge Homepage tabbed page, and the details of this subnode are displayed in the second part of the tabbed page. The second part now includes the HomePageURL text field. This text field contains the text "Any text" by default. The presenter enters a URL in the HomePageURL text field.]

Back to top