UIU Blog

What is Audit Mode?

Although the feature has been an option since Windows 7, it has become increasingly necessary when deploying Windows 10 operating systems. Audit Mode allows the OS to enter a state using only the default, built-in Administrator profile so that system and application settings are only applied to the single instance of the profile. This becomes crucial in the preparation of a base image used in OS deployments, enterprise-wide.

Why is Audit Mode a thing?

Because Microsoft Sysprep is a thing… Windows 10 employs a method of Application Provisioning that can cause problems with Sysprep. During the OOBE (Out Of Box Experience) process, profiles (in addition to the built-in Administrator profile), will be created. As applications are installed, either as a function of the OS install or by the Technician, Windows 10 Application Provisioning will apply settings to available profiles which may cause Microsoft Sysprep to fail during execution.

For more information, please review: Sysprep fails after you remove or update Microsoft Store apps that include built-in Windows images

How do I use Audit Mode?

Step 1 – Boot the base image PC (Windows 10) to Audit Mode

Remove the base image PC from Internet Access.

Establish the base image; install the Windows 10 operating system, presumably from DVD media.

After Windows installs necessary operating system files, (potentially requiring several reboots), the administrator will be presented with customization options.

---

Settings Dialog Box



Do NOT select any options on this screen!

---

Instead, initiate Audit Mode with the key combination CTRL+SHIFT+F3. The machine will then reboot and enter Audit Mode. This will prevent the creation of user profiles and the built-in Administrator account will automatically sign-in. A Sysprep dialog window will launch and should be minimized.






In Audit Mode, the built-in administrator account is enabled by the system and allows the administrator to make all changes desired. Once sysprep is executed (with OOBE), this account will be disabled by default. For more information, please review Enable and Disable the Built-in Administrator Account.


It should be stressed that Windows Store apps must not be allowed to automatically update (which they are set to do by default). It is strongly advised to leave the machine disconnected from any networks until Windows Store apps can be disabled from updating automatically, or leave it unplugged for the duration of setup.

To disable Windows Store automatic updates:

• Run: gpedit.msc (elevated privileges)
• Navigate to Computer Configuration > Administrative Templates > Windows Components > Store
ul>



---


gpedit.msc



Select “Enabled” for the setting: “Turn off Automatic Download and Install of updates”


---




After Windows Store Apps automatic updates are disabled, attach the base image PC to a network with Internet Access.



Step 2 – Customize the Windows 10 image

With Audit Mode enabled, all changes to system (OS) settings as well as application settings will be made to the Default User profile which will be used later to create local PC users. Consider two types of applications that may be installed. Applications that are installed from executable files (e.g. setup.exe) will be referred to as Application Installations. Applications that are part of the Microsoft Store (provisioned applications) will be referred to as Microsoft Provisioned Apps.

Application Installations may be launched from Windows File Manager by browsing and launching the appropriate executable.

In order to install Microsoft Provisioned Apps, it is recommended to utilize PowerShell with the integrated module, PackageManagement or OneGet. PowerShell may need to be launched manually from the Windows folder.

Navigate to C:\Windows\syswow64\WindowsPowerShell\v1.0 and then execute the powershell.ise application.

In order to enable the installation of software from a package provider, rights must be extended to run scripts:

Set-ExecutionPolicy Unrestricted

Next, a package manager or provider must be selected. The package manager requires unrestricted script execution policy, which is why it was set first thing after PowerShell is launched. Add the provider using the Get-Packageprovider <PROVIDER> command.

More information on this command can be found here: Get-PackageProvider



Step 3 – Install the software required on all machines

In order to install Microsoft Provisioned Apps, apply the Install-Package script.

For example, to install Google Chrome, Adobe Reader, 7Zip and Brave:

Find-Package –Name GoogleChrome, AdobeReader, 7zip, Brave | Install-Package

The system may require a reboot to install an application and will return to Audit Mode post-reboot.



Step 4 – Installing Windows Update (if desired)

The Windows Update Center is dependent upon OOBE mode in order to apply updates and will fail in Audit Mode for operating systems newer than Windows 8.1. In this case, the PoerShell module PSWindowsUpdate may be used.

Windows Update PowerShell Module

Excerpt from Technet:
Module can be installed manualy (sic) by downloading Zip file and extract in two places:


• %USERPROFILE%\Documents\WindowsPowerShell\Modules
• %WINDIR%\System32\WindowsPowerShell\v1.0\Modules
Be sure to run the PSWindowsUpdate.cmd, As Administrator. After all available Windows Updates have been applied, the extracted module may be removed from the Windows folder.



Step 5 – Remove built-in applications (optional)

If desired, built-in applications may be removed using the following scripts: (This may no longer be a complete list)

Get-AppxPackage *Twitter* | Remove-AppxPackage
Get-AppxPackage *CandyCrushSaga* | Remove-AppxPackage
Get-AppxPackage *solitairecollection* | Remove-AppxPackage
Get-AppxPackage *bingweather* | Remove-AppxPackage
Get-AppxPackage *bingnews* | Remove-AppxPackage
Get-AppxPackage *bingsports* | Remove-AppxPackage
Get-AppxPackage *3dbuilder* | Remove-AppxPackage
Get-AppxPackage *windowsalarms* | Remove-AppxPackage
Get-AppxPackage *Appconnector* | Remove-AppxPackage
Get-AppxPackage *windowscalculator* | Remove-AppxPackage
Get-AppxPackage *windowscommunicationsapps* | Remove-AppxPackage
Get-AppxPackage *windowscamera* | Remove-AppxPackage
Get-AppxPackage *officehub* | Remove-AppxPackage
Get-AppxPackage *skypeapp* | Remove-AppxPackage
Get-AppxPackage *getstarted* | Remove-AppxPackage
Get-AppxPackage *zunemusic* | Remove-AppxPackage
Get-AppxPackage *windowsmaps* | Remove-AppxPackage
Get-AppxPackage *Messaging* | Remove-AppxPackage
Get-AppxPackage *ConnectivityStore* | Remove-AppxPackage
Get-AppxPackage *bingfinance* | Remove-AppxPackage
Get-AppxPackage *zunevideo* | Remove-AppxPackage
Get-AppxPackage *onenote* | Remove-AppxPackage
Get-AppxPackage *people* | Remove-AppxPackage
Get-AppxPackage *CommsPhone* | Remove-AppxPackage
Get-AppxPackage *windowsphone* | Remove-AppxPackage
Get-AppxPackage *photos* | Remove-AppxPackage
Get-AppxPackage *WindowsScan* | Remove-AppxPackage
Get-AppxPackage *windowsstore* | Remove-AppxPackage
Get-AppxPackage *Office.Sway* | Remove-AppxPackage
Get-AppxPackage *soundrecorder* | Remove-AppxPackage
Get-AppxPackage *xboxapp* | Remove-AppxPackage
Get-AppxPackage *XboxOneSmartGlass* | Remove-AppxPackage


 

Step 6 – Preparing to use the UIU


UIU Classic

Within Audit Mode: Run the UIU Classic (including the import of or creation of a Sysprep answer file)

Shutdown and capture, then deploy.


UIU5

Within Audit Mode: Complete the base image setup by executing Sysprep with appropriate flags:

C:\Windows\System32\Sysprep\Sysprep.exe /unattend:<path to file>\filename /generalize /oobe

For more information, please review: Methods for Running Windows Setup

Shutdown and capture, then deploy with the UIU 5 product:
UIU 5 - Quick Steps


UIU Plug-ins 2.0 for MDT/SCCM

Assuming that a base image was created and imported into MDT or SCCM:

Within Audit Mode: Complete the base image setup by executing Sysprep with appropriate flags:

C:\Windows\System32\Sysprep\Sysprep.exe /unattend:<path to file>\filename /generalize /oobe

For more information, please review: Methods for Running Windows Setup

Shutdown and capture, then deploy with the UIU Plug-ins2.0 product:
MDT UIU Plug-ins 2.0 for MDT - Quick Steps

SCCM UIU Plug-ins 2.0 for SCCM - Quick Steps

Factors:

• Yoga model laptops
• Windows 7x64
• SCCM Current Branch
• Domain Join
• USB3 Ethernet dongle

Summary:

When deploying Windows 7 x64, particular Lenovo Yoga models do not successfully initialize the USB3 Ethernet dongle driver in time for the Join Domain function to succeed during mini-setup, resulting in a failure to join the domain.

Testing:

Big Bang Support has run a myriad of tests to isolate the USB3 driver, the Lenovo dongle driver, other dongle drivers, SCCM (Current Branch) Task Sequence settings, and hardware/BIOS settings.

Results:

• The drivers (USB3 and dongle) appear to install correctly in any case.
• Non-Yoga models succeed in joining the domain (manually, through MDT, and through SCCM) each time.
• Yoga models succeed in joining the domain when their BIOS (USB Boot) is set to disable USB3. (This is an expected result with Windows 7 as it is known to have some difficulties in general with USB3). Unfortunately, this disables USB3 support.
• Incidental – the Yoga docking station will not PXE when the BIOS (USB Boot) is set to auto USB3. (Expected behavior according to Lenovo)
• Various forums have revealed that this issue, (among others), appear to plague these models…

Conclusions:

Based on our findings, (for the Yoga series laptops specifically):

• These models contain a proprietary set of on-board USB3 components, (presumably to accommodate the unique docking station connector).
• These models appear to require an extended time period in order to install and initialize the USB3 hub and subsequently the USB Ethernet dongle.
• In fact, when we manually installed the dongle driver (in WinPE), it took about 3½ minutes to simply install, which is an exceptionally long time to load. This is evidence that this is a hardware-related, timing issue.

Proposed Solution:

Add an additional Join Domain or Workgroup step to the SCCM task sequence (TS). Add the task post mini-setup; directly after the Setup Windows and Configuration task in the Setup Operating System group. This task will make an additional attempt to join the domain in the event that the mini-setup initiated join fails. Again, in the specific case of this hardware, it will attempt to join the domain after a sufficient amount of time has passed and the dongle driver (with its unusually long installation period) has successfully installed and initialized.

Other solutions researched purported to accomplish the desired effect though scripting and other complicated configurations that required creating packages specific to the Yoga hardware, (which may interfere with other makes/models).

Upon testing this procedure in SCCM Current Branch, we found that the Yoga tablet/laptop will successfully join the domain when the BIOS (USB Boot) is set to auto USB3.

Additional Information:

Furthermore, this additional Join Domain task appears to not cause an issue with other hardware, (which successfully join the domain during mini-setup), that is not susceptible to the proclivities of the Yoga hardware. Obviously, the procedure would need to be proven in any given customer environment and, if necessary, measures to isolate the additional Join Domain or Workgroup task could be scripted to isolate the process for the Yoga machines alone.

With the release of each successive new Microsoft operating system, from the most recent Windows 8.1 going back to at least Windows 2000, Microsoft tries to tell us the same thing; namely that the operating system already contains all the required drivers for all hardware components on all machines, old and new.

Arguably, with Microsoft's release of each new operating system, new drivers are included in the inbox driver store and can increasingly, successfully avoid initial problems with BSOD, and other common first-run issues. Windows 10 promises to be nothing different.

But here's what you should know. The drivers that do get included in the inbox driver store (native to the OS) are by and large generic drivers or, at the very least, antiquated versions of drivers that are multiple revisions old. While these outmoded drivers may successfully install and control the individual hardware components, interoperability with the operating system and certainly feature richness for that hardware may be impacted or altogether missing. Furthermore, the inbox drivers generally include no access to customization software.

For example, the new Microsoft Surface includes a driver for the Intel HD 4000 graphics chipset which, in fact, is discovered and installed allowing the device to operate. That said, there is noticeable performance increase when using the official, up to date driver from Intel including access to more features native to the hardware relating to frame rate and power saving technology (improving battery life), which may be considered paramount to the usefulness of such a portable device.

Also, on many platforms including the Surface, there is a noticeable improvement to SSD disk access (random and/or sequential reads and writes) when using Intel's AHCI drivers (iastor) over Microsoft's AHCI drivers (msahci).

We have found, (since 2005), that as time progresses, particularly as it extends past the release of the new OS and generally past the release of each successive Service Pack, that the quantity of drivers specific to a released OS/SP (and not included in the inbox driver store) grows substantially up to and shortly following the end of MS Support for that OS.

Microsoft has consistently demonstrated no willingness to deliver updated drivers in a time-critical or comprehensive manner; instead, they have relied upon OEM PC manufacturers (new hardware releases/sales), component manufacturers (existing hardware), and third-party software (regular OS deployments) to provide updated, OS-specific drivers.

So overall, the native inbox driver store will in fact get the associated hardware to operate with rudimentary functionality. But such generic drivers will not allow the machine to take full advantage of the hardware to which they're associated, and represent a potentially significant opportunity lost on a substantial capital business investment.

So, does Microsoft include all of the drivers you need?  Well, again, not really.

So, you're thinking about switching OS Deployment Solutions. Congratulations! You're in for a serious amount of work not only choosing a solution, but also in planning, configuring, organizing and executing the little monster. Sure, some solutions are easier than others, yet all solutions require much more effort than you think. If you're thinking, what are you talking about? This stuff is easy…, I probably can't help you. You'll figure it out, I'm sure.

STEP 1 –
First, ask yourself, Why am I doing this? Seriously, unless you're hoping to solve a mission-critical problem with respect to OS deployment, it likely won't be worth it, regardless of the foundation of your reasons; be they political, financial, technical, talent-level or fear based. Be honest and go into the process knowing the actual reasons, it'll help you most when you're attempting to choose between the various offerings out there. Side note: If the reason is purely political, you probably need to suck it up and get it done and the rest of us out here in the Interwebs will feel appropriately bad for you. We know…

STEP 2 -
When choosing a new OS deployment solution, you'll need to know what your critical requirements are. What combination of features, available add-ons or plug-ins, integration within your environment, usability, security, delegation of responsibilities and learning curve (just to name a few) meet the needs of not only your organization, but also of your staff. Make a spreadsheet and fill it out or find one on the web, or if you have an extraordinary memory for really boring details, make one in your head! (I don't recommend the latter…) Start by assuming that you're a noob and go from there. The biggest mistakes we professionals often make are assuming that we know how everything works.

STEP 3 -
Once your new OS deployment solution is chosen, planning begins. Prepare for a lot of time to be spent making sure that you know all of the technical limitations of your chosen solution. These limitations may cause you to scrap an iteration of your plan (or several iterations). If you're considering the actual reasons that you chose the solution, you'll scrap a few as you learn the caveats. Whatever time you set aside for planning, a good rule of thumb is to double it, at least. Planning covers:  solution installation (with required, supporting network services such as WDS/PXE, multicasting switches, etc.), network infrastructure requirements and resources, target machine topography, technical staff training, and end-user training (where applicable), etc.


STEP 4 -
Next comes configuring the solution. There are undoubtedly systemic parameters that must be verified if not set, either within the solution or on the network resources that will support it (or both, likely). Organize the deployment methodologies. Determine which method or methods you'll use, (e.g. PXE vs. bootable media, etc.) and exactly what hardware you'll be deploying to, neatly organized into interlaced groupings. Don't solely consider the new hardware that you've got in your lab, but also consider the hardware that's been deployed into your production environment, especially that ancient machine in accounting that has specialized software on it, developed by one guy in his basement, long dead, and it just works, so we don't touch it. Perform the laborious task of discovering and researching the implications of EVERY parameter available in the solution, (assuming that you didn't do so prior to making the choice), as these can often either save your backside - or kick it.

STEP 5 -
Finally, execute the solution, preferably in a test lab or at least in a segregated environment at first, work out the bugs (hello, forums…), and then pull the proverbial trigger when you're satisfied. If you were diligent, you'll undoubtedly be a proud and happy camper (after some beverages). If not, well… You know the drill.

 

Unsolicited Advice:

• Choose an OS Deployment Solution that can handle Application package deployment as well.


• Choose a solution that can allow you to create small, specialized groups on which unique or at least highly customized OS images may be employed.


• Choose a solution that will meet the anticipated future growth needs of your organization.


• Train your staff on the solution! Train the hell out of them!


• Use PXE, it's awesome…


• Open Source usually means no organized support effort. Factor that in…

If you considered this post to be overly alarming and elect to ignore it, good luck. If you agree with its basic tenets or elect to take it with a grain of salt, that's cool too. Either way, it has hopefully prompted you to consider a couple of things more seriously and my only hope is that it helps you in your decision somehow. You're welcome, and I'm sorry that there's no Easy button…

If you work in a Microsoft System Center Configuration Manager (SCCM) environment, you are familiar with the major challenges you face during the deployment process within SCCM's native Operating System Deployment (OSD). First, you have to locate drivers for specific hardware components, then organize and package them. Next, you need to create a task sequence to advertise to a hardware-specific collection. If any errors present themselves along the way, you have to start again from square one. On paper, it sounds easy, but in reality, when you consider how many different hardware configurations are scattered around your company, it quickly becomes an overwhelmingly complex and time-consuming process. It's a process that's necessary only because none of the native Microsoft tools features a driver database, which makes locating and managing the correct drivers a manual (and burdensome) process. Streamline your deployment process with the UIU for SCCM We can take the headache out of OSD through a fully integrated plug-in that safely and smoothly enhances and streamlines your existing SCCM 2007 or 2012 environment. Our Universal Imaging Utility allows SCCM administrators to easily advertise any UIU-configured task sequence to any collection of computers, regardless of manufacturer or model. All you need to do is create a new, or modify an existing task sequence with the UIU Machine Configuration step, and you've completely eliminated driver packages from the process. During deployment, the UIU real-time discovery tool ascertains the onboard hardware, locates the correct drivers, and incorporates them with the image deployment, ensuring that only the most appropriate drivers are staged. By using only the  latest and most appropriate drivers, the UIU makes sure that every machine boots properly after every deployment. The driver database Drivers are always the lynchpin to any successful deployment, and a pain to manage. The UIU contains a fully vetted and updated driver database that validates and maintains over 2,000 business-class drivers and 40,000 Plug-n-Play Ids for supported Windows operating systems. And the database can be set up to update automatically. Because the UIU completely automates driver management, it eliminates the need for SCCM administrators to locate, manage, and package driver files. The UIU enables IT departments to save considerable time and money by delivering a hardware independent image to any PC. - Learn more about the UIU for SCCM or request a Free Trial

As an educational institution in the age of ubiquitous computing, decisions need to be made regarding the technical support of any individual student's hardware and/or software. There are many factors that must be considered prior to establishing a policy with regard to the same. These include, but are not limited to, hardware purchasing, standardization, support commitments (how far to troubleshoot before re-imaging), deployment and logistics - and let's not forget network security. How do we support student PCs? Or shouldn't we? As with everything else, there are reasons for and at least an equal quantity of reasons opposed. Without pretending to know all of the intricacies of every type of institution and give advice on what to do, I'll simply offer up some points  for consideration. Assumptions: All students have PCs/laptops. All institutions offer some form of network-based computing resources, ranging from web pages (public or internal) to direct network connectivity. Considerations: Is PC computing required for curricula execution? Is hardware supplied by/through the institution? Is software supplied by/through the institution? In the case where hardware is supplied by the institution, cost and tuition issues aside, efforts can (and should) be made to limit the selections of make/model and operating system. Uniformity enhances standardization, reduces security vulnerabilities, leverages purchasing discounts, and reduces logistics and support costs. Student-supplied hardware could represent any make/model and could be in any state of vulnerability/security risk at any given time. The case where an institution recommends or requires students to supply their own hardware, the problems change face a bit. For example, a criterion that enters the equation is whether the institution insists on providing an OS/Software image for the student computing population. Therein lie software (incl. OS) licensing as well as compatibility and version control issues. That's a topic for another day… How is this different from supporting PC Lab machines or staff PCs? All student PCs are mobile (or at least we'll assume/consider them to be as such). As student machines may be inaccessible by network administration services at any given time for any reason and without notice, we need to consider them to effectively be considered as mobile even if they may be traditional desktop/mini-tower models. Simply put, PC Lab machines are not only under the control of some institutional entity, they are also static; they don't move around. Desktop policies can be set, physical access can be gained at will, and visual inspections can be performed with regularity. Staff machines, although they may be mobile, are still firmly under control and policies and standards apply, whereas student machines are very often an unknown and frequently present not only security vulnerabilities but also logistics and maintenance issues. How can the institution be sure that updates are regularly applied? How can the institution be sure that the machine is not infected with a digital pathogen? If student-maintained machines are to be let anywhere near an institutional network, great care should be taken to mitigate threats, not just before they infect a network resource, but also after this has inevitably occurred. In addition to the standard anti-virus and anti-malware software, strategies such as the employment of honey pots or ghost armies can misdirect and distract would-be hackers, allowing more time to detect the intrusion and respond to the threat. Let's face it, support of multifarious machines with questionable levels of security and significant limitations on institutional control is looming if not already upon us. How do we protect our network resources from the risk of infected student machines? Is standardization an option? If so, use it heavily. Mandate that all student PCs have anti-virus/anti-malware installed and updated in order to gain access to network resources. Ensure that all public or Lab PCs have AV/AM enabled on all removable devices. Keep AV/AM as well as operating system patches up-to-date! As it's not a matter of if but when, have a lockdown protocol and practice it. Employ advanced misdirection strategies as discussed above. There are or will soon be both appliance and software implementations available to make it easier to instantiate. How about break/fix? Some institutions provide break/fix services; I would wager, however, that most insist that the student take care of their PC issues on their own. This, in my opinion is strictly a liability/cost vs. service/value proposition. If the intention is to provide such a service on non-institutional machines, have the necessary waivers in place and, for the love of Homer, provide adequate training for your technicians. That said, as institutions become more and more dependent upon PC computing to execute their curricula, they may be compelled to assist students with hardware/software problems in order to maximize the effectiveness of the application of same. I hope that this is received as helpful and has provoked some thought. Please feel free to send constructive feedback.

Latest UIU Tutorial Video- Ghost Console If you are using Ghost Console to deploy your OS images, this brief instructional video will show you how to easily integrate the Universal Imaging Utility to deploy to any laptop or desktop in your environment.   The latest version of the UIU for Ghost also fully integrates with Symantec Ghost Solution Suite and Ghost Cast Server. Read more information about the UIU for Ghost

Sometimes you need to deploy a Windows OS to a PC or PCs that are not connected to a network, or to a PC that exists on a network where deployment services (PXE/network boot) are not provided. What do you do? Revert back to old sneakernet procedures and suffer the 45-60min manual setup which, due to its mundane nature, will inevitably result in a Windows configuration that is not entirely consistent? What if you have an entire office of machines that need to be imaged? Well, most modern Operating System imaging solutions include an off-network or offline option that will allow you image PCs regardless of their network connectivity. Microsoft Deployment Toolkit (MDT) is no exception. But just like any other OS deployment solution, additional considerations must be made in order to optimize this process in your environment. First, you need to determine what operating systems and applications need to be made available in the offline media package. Will you be using more than one version of Windows? What applications will the user(s) need? Which applications are you prepared to install manually (one-offs)? Be thorough. Next, configure your MDT Task sequence or sequences in a manner consistent with your network policies to ensure consistency in your environment. Now, if you simply create offline media with MDT, all applications will be included in the ISO. This can get large and unwieldy, making media creation inordinately lengthy and increase the time required to image each individual PC. See the problem? There is a solution. Create sub-folders in the Deployment Share and copy appropriate content from the Deployment Share to each sub-folder created. Next, create a New Selection Profile, choosing only the Applications and Operating Systems that are desired for the particular off-network deployment. Note that some plug-ins will require that you create a subfolder for their inclusion in the final, offline media build. Then, when the offline media is built with MDT via Create New Media, simply mount the ISO and copy the contents from the designated Content folder to a bootable, physical, removable media (USB is recommended due to the probable large size) and boot on the necessary PCs. Let the MDT Task Sequence do its trick. I know I don't have to say it, but I will anyhow; make sure to test your MDT offline media prior to use in production. Here's a sample procedure: The configured MDT environment must have ability to deploy images (prerequisite). Prepare the desired offline deployment task sequence. (According to network policies) Creating off network media If Deployment Share has multiple operating systems, applications, or packages, now is the time to create folders so that an optimized (slim) offline selection profile can be created. Copy appropriate content from the Deployment Share to each folder created. These folders may be selected individually to exclude unwanted applications from being copied to the off-network media. Under Advanced Configuration>Selection Profiles, create a New Selection Profile choosing only the Applications and Operating Systems that are desired for the particular off-network deployment. NOTE: Selecting more than what is necessary will result in larger than necessary ISO files and USB storage requirements. Once the selection profile has been created, right-click on Advanced Configuration>Media and Create New Media using the selection profile above. Remember the Save Location that you designate in this wizard for later use. Format USB drive (recommended) using Diskpart.exe. This USB drive should be large enough to hold the entire media as defined by the Selection Profile used. (As a point of note, the inclusion of Win7x64 and the off-network task sequence bare bones configuration is approximately 3 Gb in size. ) On a computer running the Windows 7 operating system, insert the USB drive. From a command prompt, run Diskpart.exe Execute the command list disk to determine the disk number associated with the device.  Input the following commands, where N is the disk number identified in the previous step:  - select disk N  - clean  - create partition primary  - select partition 1  - active  - format fs=fat32 [ntfs] [quick]  - assign - exit  Note: UEFI partitions will only boot with fat32 formatted USB drives. Diskpart.exe is a powerful utility and can cause damage to your system. Make sure to format the correct drive!  After media has been created there will be a Content folder in the save location that was chosen in step 4.c. Copy the contents of the Content folder to your freshly formatted USB. Test the bootable USB containing the off-network media for desired results before implementing the process in any production environment. In summary, although additional planning and configuration is required, Microsoft Deployment Toolkit is capable of deploying Windows operating systems and applications regardless of network connectivity or network boot services.

Utilizing the Dell KACE K2000 Deployment Appliance to deploy Windows operating systems images gives admins a fully integrated systems provisioning solution. The challenge with deploying an OS to disparate hardware still always comes down to device driver management. While KACE offers features like computer scanning and assessment, managing the unique drivers for each existing recipient machine, let alone new machines, is still a cumbersome process. Below is a solution for deploying a single OS image with the Dell KACE K2000 Deployment appliance to any laptop or desktop regardless of manufacturer or model when used in conjunction with the Universal Imaging Utility. 1.    Create an Active Directory Domain Service Account for use with the UIU. 2.    Create a Repository Folder that is a Share on a Server that will be accessible or on           the Same Subnet as the KACE Server where you are deploying the images. For Example: \\Server. Domain.com\Repository This is a Folder on the Server and is shared with the name Repository. Add the Above Active Directory Domain Service Account to the Security of the Repository Share with Read and Write Rights. Once the Domain Account is created, the Shared Doled is created and the Folder rights are assigned, open the Dell KACE Web Console of your Appliance. 3.    Install the UIU 5 using the Domain Service Account and shared Repository folder. 4.    Open the WEB interface of the Dell KACE Appliance and Login 5.    Click on the Library Tab 6.    Click on the Postinstallation Tasks Tab 7.    Click on the Choose Action… Drop Down and select Add New BAT Script… 8.    Provide the Mid-Level Task with a Name, be sure to select the Runtime Environment:          K2000 Boot Environment (Windows), then enter the following two command Lines            under BAT Script: and enter a description in the Notes: field and click on the Save         Button. Command Line 1:  Net Use \\Server.Domain.com\Repository /user: Domain\DomainServiceAccount Password Command Line 2:  \\Server. Domain.com\Repository\x86\uiuprep.exe -run -license UIU Product Key Reminder: Substitute real values for Server, Domain, Account, Password and UIU Product Key Once the Mid-Level Task is saved, add it to your Deployment Package 9.    Click on the Deployments tab and choose the desired Deployment Package 10.    Scroll down to the Mid-Level Tasks, grab the UIU Task and drag it under the Run          Mid-Level Tasks field.          Please note:  When you hover over and grab the task to drop it, your cursor will turn  into a cross arrow as shown. 11.    Scroll down to the bottom of the screen and click on the Save Button When the KACE deployment task sequence is executed, the OS will be deployed and the mid-level task(s) will invoke the UIU to perform its driver servicing operations and facilitate the staging of only the drivers required for each affected machine.

**See Survey opportunity at conclusion of post - for a chance to $100** So, you've successfully deployed your new Microsoft OS with all of the insightful configurations made to optimize performance in your environment. Excellent! Oh, wait; you're not finished yet, are you? Nope, not by a long shot. Once you're finished with the OS deployment, you need to establish to which end-user the machine will be allocated, what their specific access and application needs are, and under what conditions (network connectivity) they'll be operating. Who's getting the machine? Regardless of whether it is upper management, manufacturing, engineering, clerical or professional staff, their needs may be, (and usually are) quite different both from an applications perspective as well as a computational power perspective. What applications do they need? The application sets range from standards like Microsoft Office to highly specialized applications such as AutoCAD and everything in between. Some applications are popular and highly supported in the industry. Some are so specific to your business that they were developed by an individual either in-house or outsourced and have a much smaller support base. Delivering and supporting the applications to meet the end-user's specific needs can be a daunting challenge. Where are they using it? This is a fun one. Not all employees are sitting in cubicles in one or more offices connected by heavy duty WAN lines any longer. The increase in telecommuting (not to mention BYOD) and the needs of mobile users continue to put pressure on IT organizations to quickly and efficiently provision, configure, deliver and support effective computing solutions for competitive business. What do the responses to these three questions mean? They translate into a set of parameters that will need to be applied to the specific machine either prior to delivery or upon initial login by the end-user (or administrator on behalf of the end-user). Some of the settings may be already determined and will be set by group policy when the end-user logs in for the first time, joins a domain and creates a local profile to which group policy parameters are dictated. Other settings may be applied either manually (by administrator) or initiated through a deployment solution/3rd party solution at varying stages of provisioning. Finally, applications need to be installed and personalized for that target end-user and again, this can either be achieved manually (by administrator), or initiated through a deployment solution/3rd party solution at varying stages of provisioning. What we have here appears to be a Gordian Knot that anyone would lament being required to untie. The task of provisioning end-user machines is often underestimated with respect to the actual time it requires and with respect to the expectations of those requesting the machine to be provisioned in the first place. Have you ever been asked, Why is it taking so long to get me my new laptop? I thought so. Hardware provisioning is a process that is often greater than the sum of its parts, involving a varied and sometimes conflict-ridden selection of applications with specific pre-requirements, involving a multitude of managed systems to deploy and configure those applications for first use as well as to reestablish previously applied application settings from past session use and further involving many different infrastructure-specific components to allow access to the data manipulated by the applicable applications. It's a difficult proposition and furthermore it's difficult to find, analyze and implement solutions with a complicated variety of hardware, applications and end-user needs. Hang in there!