Back to basics: Configuring a static IP address on Windows 10

Posted on June 30, 2022 by jasonrw

Static IP addresses ensure that the computer’s hostname aligns with the designated IP address in Penn’s DNS service. To configure properly, one will need the correct IP address, correct subnet mask, default gateway, and two addresses for Penn’s DNS servers. All of those items can be had for the asking. DO NOT make any configuration changes without having all of the correct values described above. Local administrative privileges will also be needed to do this.

Windows 10 offers two ways to configure a static IP address through the GUI . The first way is with the new System application. Second is through the traditional Control Panel (control.exe). The first way is problematic and never saves any manually entered configuration. Don’t use it. Instead, this tutorial will focus on configuring a static IP address through the Control Panel.

We’ll configure the following values for example.
IP address: 192.168.1.25
Subnet mask: 255.255.255.0
Default gateway: 192.168.1.1
DNS 1 & 2: 8.8.8.8, 8.8.4.4

1. To start, search for “control.exe.”
2. Select (click) the “Network and Sharing Center” applet.

3. From the top-left, select the “Change adapter settings” link (under the “Control Panel Home” link).

4. A new window will appear, showing all installed network adapters. Double-click the adapter titled “Ethernet.”

5. Click the “Properties” button. Admin username and password will be needed.

6. Next, click the “Internet Protocol Version 4 (TCP/IPv4)” item and then click “Properties.”

7. Fill-in the blanks in the resulting window and click “OK” to close the dialog boxes and save the new settings.

Just like houses on a street, no two can have the same address. The same goes for IP addresses. If two computers have the same IP address, neither will remain online. Make sure the IP information being entered is correct before proceeding.

Provisioning in a Post-Imaging World

Posted on January 31, 2021 by jasonrw

Is this the end of MDT? The end of imaging as we know it? The Windows 10 operating system has made bare-metal OS management much easier. With utilities like “Reset this PC”, the only time a fresh copy of the OS needs to be installed is on new hardware. Even upgrading hardware such as hard drives, from HDD to SSD doesn’t require a fresh install. The traditional DISM.exe utility allows for capturing a WIM file from drive partitions for application on different hardware, but it won’t image a whole disk. Third party utilities like Acronis TrueImage and Macrium Reflect make transferring an existing Windows install to different hardware a snap.

What does our organization do to set up new PCs for our users?

Image? No longer, we provision. Bigfix, our endpoint management system, allows for control of Windows’ every facet. With that, we can install all of the software we need end users to have and configure all of the settings as per organizational policy. Bigfix even offers a self-service option for applications that may need to be installed later on, by end users, without admin access.

The Windows Configuration Designer (WCD) can run an automatic setup for a fresh Windows install, coming out from OOBE. Just place the PKG file on a USB key, insert USB into the target computer and boot. Setup first-run will ask if you want to apply the PKG file and that’s it. Depending on the config options chosen when building the package, you’ll have a desktop that is ready for software deployment when finished. WCD is not a complete desktop deployment solution, but it can get you through the inane first run questions, set up a local admin user and install small applications such as the Bigfix client. Once WCD is done, I can manage the PC through the Bigfix console.

We no longer have to replace one operating system with a customized version of the same thing. Provisioning is not the biggest timesaver in IT but it reduces the time spent performing repetitive tasks which should be automated. Bigfix can even upgrade the Windows Sku from Pro to Enterprise per our organization’s license agreement with Microsoft. If a hard drive fails, then we’re reinstalling on replacement hardware. Aside from that, we’ve found no reason to perform fresh installs anymore. Windows Reset works well along with System Restore to roll-back changes or just start from fresh.

Group Policy-Managed Desktops Preferences

Posted on February 4, 2019 by jasonrw

Starting with Windows Server 2008, Microsoft added a feature to Group Policy called “Preferences” (GPP). This allowed administrators to configure Windows settings Control Panel-style. Just like GPOs, GPPs contain dozens of configuration possibilities and when used properly, can make administration much easier. GPPs are divided into Windows Settings and Control Panel Settings, similar to a GPO. Each GPO has a set of preferences in both the Computer and User configuration settings.

Here’s how I use them on public computers.

Computer Configuration\Preferences\Windows Settings\Registry

Update = HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp, Value name = PortNumber, Value type = REG_DWORD, Value data = desired RDP port in hex
Update = HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters, Value name = srvcomment, Value type = REG_SZ, Value data = Whatever you want the end users to see in the System properties pane.
Update = HKLM\SYSTEM\CurrentControlSet\Control\CrashControl, Value name = AutoReboot, Value type = REG_DWORD, Value data = 0x1

Editing registry settings en masse is a very powerful capability which can fix or create problems nearly instantly. I add a few tweaks to Windows. The first one changes the port number that Remote Desktop (RDP) listens on for connections. The default is 3389. I change that in addition to creating custom a firewall rule for the new port and scoping it to only include allowed IPs. The second entry adds a comment in the “About” section in the Windows System Control Panel applet. The last value forces Windows to reboot whenever it decides to crash and not present the user with a BSOD.

Computer Configuration\Preferences\Windows Settings\Shortcut

Update = Target type = Shell object, Shortcut path = %CommonDesktopDir%\This PC, Target object = This PC, Icon path = %SystemRoot%\System32\SHELL32.dll, Icon index = 15, Run = Maximized

Places a shortcut on all users desktops called “This PC” which is similar to the legacy “My Computer” icon of old. I do this for reasons of familiarity.

Computer Configuration\Preferences\Control Panel Settings\Printers

Delete = Local printer “Send to OneNote 16”

Windows and Office like to make the OneNote printer the default for everyone. I delete the printer object for OneNote 2016 so installed printers, after the fact, can be the default. I don’t commonly map printers on public computers, but some labs use a Pharos unit for printing and wherever possible, should be the default.

Group Policy-Managed Desktops, Part 1.

Posted on February 26, 2018 by jasonrw

Hello,

Administering classroom computers is an exercise in uniformity. My mandate is to make the end user experience identical in any classroom a professor might teach. The options to standardize settings are two-fold, curate a custom default user profile in Windows, or use Group Policy.

Microsoft introduced Group Policy to Windows 2000 when that product was still in beta. Group Policy allowed administrators to specify and enforce any setting available to them in the policy. As Microsoft progressed in developing Windows, Group Policy followed bringing more options to administrators. Every domain-joined Windows computer and domain users are subject to several group policies without any specific changes being made. Windows Active Directory (AD) domains come with two default Group Policy objects (GPO). Starting with Windows 2000, every “Professional” or “Enterprise” version of Windows which was based on the NT kernel came with a local Group Policy object. Anything that can be set in a registry key, can be set through Group Policy. Windows Server 2008’s version of Group Policy introduced the ability to specifically set preferences for Windows and its users along with the regular policies.

An administrator can completely control Windows desktops and servers through a Group Policy object. Software using MSI installers can be deployed with Group Policy. When set up correctly, Group Policy can be a very handy administrative tool. If it is set incorrectly, Group Policy can be a challenge to troubleshoot and fix. The effects of a GPO are widespread and can apply to every computer or user in the domain or an OU just as easily. A desired change can spread just as quickly as a detrimental mistake through a GPO. Most important of all, a good GPO can end the days of admins having to visit each computer to change settings en masse.

The basics of Group Policy are simple to understand. Any user or computer underneath the scope of the GPO will receive the settings specified. Despite the name, Group Policy does not directly apply to groups, though it is possible to configure it that way with application permissions. Normally, objects being managed by a GPO must live in an object under that GPO whether it is a domain or an OU. There are exceptions to this, but we’ll hold off on that for now. Since a single Active Directory object could theoretically have several GPOs applied at the same time, GPOs have an order in which they are applied.

First, any and all settings from the local GPO are applied to all users and that one computer. Local GPOs only affect the computers on which they’re stored. This is the only way a user or computer not joined to an Active Directory domain will receive settings from Group Policy. Local GPOs are helpful if an AD domain in not in use or available. However, I do not recommend their use in AD domains because their change has to be done at the local level. Then, admins are back to running around. I’d use a local GPO to enforce settings that I know will never ever need to be changed. The number of possible settings that would fall under that description are pretty small. A good example is the GPO setting that enables/disables Windows 10’s sign-in animation. I always disable it. No one likes or appreciates Microsoft’s new animated approach to a first-login progress bar.

Second, is the Active Directory Site. As much as a Site would seem to equate to a physical location, it does not. AD Sites are groupings of domain controllers (DC) either from within the same domain or from multiple domains in the same AD forest. Sites are purely for configuring replication policies. Active Directory replication is automatic within a site (default). Replication across sites is not automatic at all and must be set up manually. I have never needed to use a GPO at the site level outside of a test lab, ever…

Third, is the Active Directory domain. Every AD domain within an AD forest ships with two default GPOs, the “default domain GPO” and the “default domain controllers GPO.” The domain GPO lives at the root of the domain while the DC’s GPO is attached to the domain controller’s OU. They are the only default GPOs Active Directory provides. They’re not the only GPOs possible within Active Directory. Many many more GPOs can be created at the domain level for whatever reasons the administrators decide is best. Settings which are appropriate for every computer and user in the domain, DCs too, are best at this level. Those settings are often not too specific in every example, but can be very helpful in providing a baseline configuration that all computers should have. For example, the Windows Firewall’s setting of “protect all network connections” can be enforced for every computer in the domain, including sub-level OUs. Any required firewall rule exceptions can be defined in that same GPO. Antivirus software or endpoint management client software can be deployed with Group Policy at the domain level. As soon as a new computer joins the domain, it gets the assigned software if the software is not already installed.

Lastly, the Organizational Unit (OU) is the final place a GPO can be applied. All GPOs, no matter where they are applied, have the same settings. At the OU level, configurations can become very specific. This design can level down with OUs having sub-OUs, each with their own GPOs. The settings here are good for one particular group of users or computers can be placed within an OU and administered as necessary. This how I organize my classroom computers in our domain. I have it set that any Windows computer that is placed in the classroom OU can be working as such without any local modification necessary.

All settings from all assigned GPOs will apply to a user or computer in the order of local, site, domain and OU. In the event of a conflict in settings between GPOs, whether from GPOs at different levels or from the same level, the setting from the GPO applied last wins. There are, of course, exceptions to this rule, but we’ll deal with that later.

What will be the best way to approach a GPO to configure your end user’s computers is determined by figuring out what should be controlled and how to provide that configuration. Some settings can be configured and built into the operating system image. This is a fine option, but it lacks versatility. Suppose the configured setting’s requirement changes or the determined setting was incorrect. To remedy this, a new image must be created and those computers already-deployed with the previous image will need to be fixed. The same setting deployed with a GPO would just need the proper adjustment in the GPO. No new image needed. No visiting end user computers or concocting exotic repair scripts.

The latest work I have done with Windows 10 shows that an image without a pre-configured custom default user profile has the quickest login time for new users. In a classroom environment, fast logins are very important. End user profiles are not kept on classroom computers for reasons of privacy. Every time someone logs into one of my classroom computers, they are doing so for the first time whether they have done so in the past or not. A login time of 90 seconds can be tedious for a 45 minute class. The recipe to ensure fast logins is to not modify the default user profile. Let the Windows default profile (2-5 MB in size) be what everyone gets. How then are the settings end users need provided to them? Group Policy. I use Group Policy to control the behavior of the Windows 10 operating system, Microsoft Office 2016, Mozilla Firefox, Google Chrome, and Adobe Acrobat Reader DC. Everything from what the user sees on the login screen to the default file type associations are set by a GPO.

The next steps are to compile a list of all the desired configuration settings and then map them to their respective GPO settings. If a GPO setting does not already exist for the changes trying to be made, see if a GPO template is available, or use Group Policy to distribute a registry edit which will change the desired setting. Group Policy is extensible. Each time Microsoft releases a new build of Windows, new GPO templates come with it. Third party software vendors such as Adobe and Google graciously make GPO template files available for their products. By default, Group Policy will only cover the Windows operating system. To manage Microsoft Office or any other product, the proper GPO templates have to be added to a Group Policy Central Store, which is configured on a DC, manually, by administrators.

Given how easy it is to change settings for Windows through Group Policy, a small mistake has the potential to become a large problem quickly. I practice due diligence in this respect and test every desired GPO change in a dedicated test environment before it is implemented on the production network. No exceptions… If you’re new to Group Policy and have little to no understanding of it, leave it alone until a rudimentary understanding is held. There are ample resources for learning Group Policy online. Try all GPO-related ideas in a test environment. Make sure the test environment is a representation of the production network. The closer the resemblance between the test network and the production network, the more accurate test results will become. There should be as little room as possible for surprises from a GPO setting implemented on the production network that was implemented successfully during testing.

Once a concise list of the settings needed to give the end user the desired environment is compiled, implementing in a test environment is the next step. Depending on the starting point, the settings can be few or they can be extensive. To make GPO management simpler and to not reproduce identical settings in other GPOs elsewhere, I create my GPOs to do one or two specific things. A giant, all-encompassing GPO, which sets everything desired, is compact but not always the best idea. A GPO with dozens of configured settings is difficult to troubleshoot. Several changes will need to be made/unmade to that large GPO to see which one in particular might be the problem. On the other hand, a GPO dedicated to configuring Microsoft Office, Mozilla Firefox, firewall settings, Remote Desktop settings can be applied/unapplied wherever needed and tested much easier. Testing one change at a time is more productive than testing several at the same time and hoping they all work. In the event that a GPO has to be unlinked from its assigned OU, only those settings are removed. All other working settings remain applied from other GPOs. Maybe after a period of successful implementation with no instances of GPO-induced problems, all settings could be rolled into one “known good settings GPO” and applied.

In the next part, I’ll detail the exact settings I use to provide my users with the desktop experience they need to teach their classes without technology getting in the way.

Thank you

Time Shifting Part 2

Posted on January 27, 2018 by jasonrw

Hi,

A few months later, we’re still at an impasse over how and why Windows 10 Enterprise 1607 x64 loses time on the taskbar’s clock. Part 1 detailed the problem and some of my early attempts to fix it. Many of my colleagues are surprised when I tell them about this problem and often have no idea why. The first response is “check the BIOS/CMOS battery” (first thing I did), then ask “What are the NTP settings? (default).”

One lead which brought forward some interesting information was the health of the SSD in one of the affected computers. After running the Intel SSD utilities on the drive, it was over tolerance in the read/writes dept. In the span of two and a half years, the 180GB SSD wrote 37TB of data to the drive. The drive’s health was “good” but over tolerance. That figure seems large to me, but considering that we wipe user profiles at logoff and every user gets a new profile every time they log in, it makes sense. The default user profile is around 500MB in size. The login process occurs on an average of 5 times per day (MMV), five days per week (sometimes six), 39 weeks per year. This is just logging in and logging off, not considering Windows updates, AV definitions, whatever BigFix writes to the drive and any other Windows processes.

Aside from the time shifting issues, Microsoft Windows 10 runs fine, albeit under strict control. While this problem seems intermittent, it is easily dealt with by the end user. Simply, move the mouse, or perform a key press, and the screen will refresh to the correct time. Students taking exams or performing timed assignments were the first to notice the time-shifting problem. Several websites are available that show a clock on the center of the page, along with some ads. Their text is much larger and easily seen by students, including those in the back rows. During my exams, some professors would show these types of webpages or use a watch or the clock on their smartphone as a timer and would announce the time remaining at thirty or fifteen minute intervals.

These alternatives are suitable for the time being, despite the fact that the builtin Windows clock should be a reliable time source without any question. Going forward, I’ll continue to monitor the progress of this issue and hope that build 1709 or 1803 brings one of those silent fixes.

Thanks!

Creating Task Sequences for MDT

Posted on October 20, 2016 by jasonrw

Applications, operating systems, drivers are all great but do nothing without a working task sequence. Task sequences are basic XML files which call on a series of scripts to run parameters chosen by the user, when the task was created. There are a few different types of task sequences, some for capturing images, some for deploying software, but most center around deploying an operating system image to computer hardware. That is where our focus will be.

The simplest way to get started with a new task sequence is to right-click the Task Sequences folder, and choose “New Task Sequence.” Like other areas of MDT, some thought should be placed into how this is laid out. Just like we did with the Operating Systems folder, I like to arrange the Task Sequences folder according to OS, and image type. I actually create the same folders in the Task Sequences area so that they mirror the Operating systems folder.

MDT’s operating system and task sequence folders are the same.

Generally, one operating system image goes along with a single task sequence. I haven’t run across the need to use the same image with multiple different task sequences. Creating folders is just as easy as starting to create a task sequence, right-click the node above and choose “New Folder.” Also, if one was to create an offline MDT deployment share, separated tasks and operating systems can make your selection profile much slimmer.

The process of creating a new task sequence is wizard driven like many things in MDT. Each task needs a unique ID for starters, and a name which can or can not be unique. The ID becomes the name of the folder for the task sequence in the deployment share’s file system hierarchy. I like to use a truncated version of what the task sequence does for the ID. Example: DEPW7EX64 for deploying an image of Windows 7 Enterprise x64, or CAPW7EX64 for capturing an image. Whatever works is fine just as long as each ID is unique. The name and description should be concise and meaningful as it is shown to the one doing the imaging on the image selection screen, from Windows PE.

Select a unique ID and meaningful a name and description.

Next, is the place to select the type of task sequence being created. There are several types, the one we’re looking for is “Standard Client Task Sequence.”

For our example, choose the Standard Client Task Sequence

Next, we need an image to deploy. Here’s another example where a little organization can pay off down the road. In this case, making the images easier to find. We’re going to choose the basic install image of Windows 7 from the ISO.

Choose the desired OS image.

Windows needs a product key to be legit. The next screen presents three options for a product key: none, a MAK key, and a retail product key. I choose to use KMS activation for my deployments, and rely upon a scripts to point Windows to the KMS server, enter the key, and activate. The script was added to MDT as an application and is run that way. However, if MAK activation is the way to go, here’s the chance.

I typically do not enter a product key at this stage.

Next, we have to enter some OS information. I use the persons or organization to whom the software is licensed. Keep in mind that the home page URL is for Internet Explorer only.

Here, I enter the registered owners and/or organization of the software license.

The next step asks for the password of the local administrator account, the built-in administrator. I enter a basic password here that will be changed later on. Keep in mind the password IS obfuscated in the resulting unattend.xml file, so it is safe there. I actually have a task disable the built-in administrator account from BigFix, after imaging has completed.

Enter a password for the built-in administrator account.

The following steps are a summary screen and a finish. Those can be passed through with Next and Finish. Now, we have a basic task that will deploy Windows 7 without much customization.

The completed task sequence.

To get a bit more out of it, especially where driver insertion is performed, we’ll need to edit the task sequence and add a couple of steps. Just right-click the task sequence and choose “Properties.” The General page lists all of the settings entered before, lest they be changed now. I usually don’t mess with those all too much. I do, however, get into the Task Sequence tab. Here are the steps MDT processes, sequentially, when executing a task sequence.

I like to have firm control over which drivers are used on the imaged PC, so I tell the task sequence exactly where to look, and leave little for MDT to figure out. The first step to this is to add a Task Sequence Variable which will identify which drivers to use. Choose “Add” from the top menu, and track down to “Task Sequence Variable.” Place it in the “Preinstall” section, right above the inject drivers step.

Variable above the Inject Drivers step.

Set the variable name to “DriverGroup001”, and the value to “Windows 7 x64\%Make%\%Model%” (without quotes). This convention follows a previous post I have about driver management. If you followed the steps there, these will compliment them.

$DriverGroup001 \ Windows 7 x64\%Make%\%Model%$

DriverGroup001 \ Windows 7 x64\%Make%\%Model%

Next, we have to modify the Inject Drivers step from allowing all of the drivers on the deployment share to only the ones found at “Windows 7 x64\%Make%\%Model%.” To do this, change the selection profile to “Nothing”, and choose the radio button titled “Choose all drivers from this selection profile.” This will turn off automatic driver detection and just use the drivers found in “Windows 7 x64\%Make%\%Model%.”

Selection Profile = Nothing / Choose all drivers…

In a very basic sense, we’re done. MDT will install Windows 7 and only use drivers detected by WMI for the installed hardware. This is a quick way to get up and running with a basic Windows install. However, additional steps can be added to sweeten the task sequence.

In the “State Restore” section, one step we really don’t have to touch is “Install Applications.” In its default state, the MDT wizard will prompt the end user to install any or all applications listed on the deployment server. This is good for versatility, but can get a bit repetitive if done many times. To get around the prompt and have MDT install the necessary applications, I create an app bundle, add my desired apps to the bundle and have the Install Applications step just run that. For example, my bundle is called “Windows 10 Classroom Software.” It contains Symantec Endpoint Protection (SEP), the BigFix client (IEM), and the Sassafras K2 client. The main reason why I do not build these into the image is that their values need to be unique on every installed instance. I could install them on a template computer, and remove their unique components, but it is just as easy to install them during deployment. Even though the name says “Windows 10 Classroom Software” it will run on Windows 7.

Create an application bundle and have MDT install that.

Now, our virgin Windows 7 install will have antivirus software, and endpoint management software, which is pretty much everything we need for our working environment. I could use MDT to install Microsoft Office and anything else, but BigFix will do so too.

MDT and Drivers

Posted on September 25, 2016 by jasonrw

Drivers are a big part of getting Windows to work properly. Anyone who has ever had to troubleshoot a piece of hardware on Windows knows this. When generalizing an installation of Windows for capture with sysprep, all but the most basic drivers are removed. This makes the captured image applicable to many different types of hardware. During a task sequence, MDT runs a plug and play check, for hardware at a couple of different points to determine what drivers, if any, are needed. When a matching driver is found, it is injected into the image before it is applied to the computer’s hard drive. To do this, MDT has a folder/section in the deployment share that is dedicated to organizing and storing drivers. It is called “Out-of-Box-Drivers” (OOBD).

The basic INF files are what MDT needs for driver injection. Many drivers are distributed as packages, which come in the form of an executable. This is not what we need. If an executable is the only way a driver is available, it must be imported as an application into MDT, and installed via task sequence. Fortunately, OEMs like Dell, Lenovo, HP, and even Microsoft make bulk downloads of model-specific drivers available from their sites. Dell hardware drivers come in the form of a CAB file, which can be opened with the expand command, or with a compression/decompression utility like 7-zip.

Bulk-driver Download Sites for Dell, Lenovo, HP, and Microsoft (Surface)

I create a folder structure on the MDT server similar to “Drivers\Windows ##\Vendor\Model.” For example: D:\Drivers\Windows 7\Dell\OptiPlex 990

I do not delineate between x86 and x64 versions of drivers in my folder path because nearly all of my OS deployments are 64-bit. Dell combines x86 and x64 drivers in the same download. Many Dell drivers can be used on both platforms. Lenovo drivers will try to extract to their own, specified path, but that can be changed at runtime. Complete, downloaded driver packs can be between 300MB and 1,000MB in size, except for WinPE driver packs which are very small.

Using the expand command, I’ll extract the drivers to my folder structure.

expand C:\Users\jasonrw\Downloads\990-OptiPlex-ABCDE.cab -f:* “D:\Drivers\Windows 7\Dell\OptiPlex 990”

The command prompt window will scroll really quickly and end with the prompt returning. Now, we can import them into MDT. MDT is able to handle drivers in different manners. The basic default option is to throw all drivers into the same folder at the root OOBD directory. With that, a deployment task will search the entire OOBD store for the right drivers. This increases the chance of the wrong driver being selected. WMI is great, but it is not perfect. Another option is to break down the OOBD store by manufacturer/vendor or by operating system version. Creating folders for Windows 7 and Windows 10, respectively can help minimize the chance of a wrong driver being installed. I take it one step further, actually a couple of steps further. I still use MDT’s WMI hardware-querying capabilities, but I tell it exactly where to look.

I create a specific folder structure under OOBD that matches a specific WMI query I pass on to the deployment task. For example, Windows 7: Out-of-box-drivers\Windows 7\Dell Inc.\OptiPlex 990

The bottom two folder tiers each correspond to variable in a WMI query, Make and Model. To find the make or manufacturer of an OEM PC, run the following command from a command prompt.

wmic computersystem get manufacturer

The returns for Dell and Lenovo are “Dell Inc.” and “Lenovo”

To get the model, run the same command as above, but replace “manufacturer” with “model” Top that off with a folder for OS version and platform, and you have something to use. In the task sequence, a task variable can be inserted into the PreInstall phase, before the inject drivers step to tell the task sequence exactly where to look. The variable is “DriverGroup001”, and the value is “Windows 7 x64\%Make%\%Model%” This will allow a task sequence to correctly use a WMI query to find the drivers for the exact make and model being imaged.

The Inject Drivers step has its own settings that needs to be configured. For our purpose, the selection profile has to be set to “Nothing” with all drivers from the selection profile being used.

Selection profiles are the ultimate step toward driver control. They are a pre-defined selection of drivers that may encompass and individual model, or manufacturer. MDT ships with a few pre-defined selection profiles, but more can be created to suit any need. Given the exact control this approach provides, there is one detraction, it limits task versatility. Since a selection profile tells a task sequence exactly which drivers to use, MDT doesn’t query for them. The default setting for Inject Drivers is to query the entire OOBD store, but when “Nothing” is set, they querying is off. If it is desired that a task sequence only serve one or two makes of computers, this might be a good approach. I support about a dozen different models from two manufacturers, and I’d like my task sequences to be applicable to all.

I do use a selection profile to organize the drivers I use for my MDT Windows PE ISO/WIM files. Dell and Lenovo make drivers just for Windows PE available as a download too. I use the same approach as above to download, extract, and import the Windows PE drivers into MDT. Then, I create a selection profile for the Windows PE drivers and use that for my ISO/WIM file drivers.

To import drivers into OOBD, make your folders as desired, right-click the folder for the computer model, and choose “Import drivers.” A wizard will open, walking you through the process of importing the drivers from where they were extracted. It is real easy.

After the driver import, the deployment share must be updated. By default, MDT uses the all network and system drivers it has in the OOBD store for the Windows PE ISO/WIM file. This can be changed, as I described above, with a custom selection profile, but it is not mandatory. Still, note, that each time drivers are added and removed, the deployment share should be updated for those new drivers to be used. Some drivers are clearly depicted whether or not they are x86 or x64. In reality, many single drivers can be used on both platforms, but the descriptor files do not always indicate that to MDT. Thus, MDT will import the driver and override the specified platform. This is noted after all of the drivers have been imported for that operation.

I, personally, write down the name of each driver with a warning, and disable them after the wizard ends. Disabling/deleting a driver is easy, just right-click it in the MDT workbench and choose the appropriate option. Drivers must be disabled from their property sheet. Disabling a driver is a safe approach before it is determined that deletion is necessary. Only ever delete a driver from the MDT workbench. DO NOT go into the driver store via the file system and delete it that way.

Again, when disabling or deleting a driver, you must update the deployment share to take it out of Windows PE.

Finding, downloading, extracting, and importing drivers into MDT is a big part of MDT configuration, which takes a great deal of time. If it is done with forethought and planning, it can minimize the driver problems a deployment share might have, and need only be done once. I note the name and date of the driver files that I download and import into MDT. Then, I can periodically check for updates from the vendor’s web-sites. The older a model is with the manufacturer, the less-frequent they tend to update the drivers packs for that model. If the manufacturer does not make a driver pack available for your model, it is possible, though very tedious, to download each driver, and extract them individually. I try to avoid doing that.

Thanks!

MDT, Getting Started

Posted on October 30, 2015 by jasonrw

The Microsoft Deployment Toolkit (MDT), a very nice option for deploying Windows in small to large environments.

Symantec Ghost was the de facto tool we used to deploy Windows to end user computers. One big issue was that Ghost, as a product, wasn’t updated to keep pace with the new versions of Windows. Another issue with Ghost was driver management. There was no easy and reliable way to configure a central driver store that the images could use, so multiples images, one for each hardware type, had to be kept. MDT uses a shared, central store to keep drivers. Initially, Ghost was able to automatically reboot client into an image task via a desktop agent. As Windows progressed in development and Ghost stagnated, the compatibility with Windows PE, the tool used by Ghost to start a computer into an imaging task, became nil. To use Ghost, at the end, each client computer had to be manually started into an imaging task with a USB boot key.

The requirements for any new imaging system included a hardware-neutral image creation process, a central driver store, and the ability to remotely initiate an imaging task on a client computer (zero touch). Two out of three isn’t too bad. MDT offers the ability to use a hardware-neutral imaging process with a central driver store, but it doesn’t specifically offer zero touch imaging. The higher-end product, Microsoft System Center, does. MDT is centered around a lite touch approach which requires a minimal, and manual interaction with the target desktop. Many settings, however, can be automated to the point of complete autonomy. Best of all, unlike Microsoft System Center, MDT is free of charge.

To use MDT version 2013 Update 1, Windows 7 or better is needed as a source platform. I tested with a proper version of Windows Server 2012. Windows Server is required at some point for PXE-booting capability via Windows Deployment Services (WDS). WDS will allow a PC to boot to a network-based Windows PE image, created with MDT, and commence imaging. Windows Server will also support more than ten simultaneous SMB connections unlike a desktop version of Windows. An essential part of setting up MDT on a server is the Windows Assessment and Deployment Kit (ADK) for Windows 10. The ADK contains the tools necessary to create the deployment infrastructure for MDT, most notably Windows PE.

For example:

Install Windows Server 2008 R2 or better and update it to it’s fullest extent (that may take a while), in addition to installing antivirus software and joining an active directory domain (optional).
Then, install the ADK for Windows 10, which covers deployment for Windows 7, 8, 8.1, and 10 as well as the servers. If there are no plans to use the MDT database with the server, SQL Server Express need not be installed with ADK. SQL can always be added later if the requirements change. Reboot the server.
Install MDT 2013 Update 1 on the server. If you’re unsure over which version of ADK or MDT to install, go with the x64 version. In my experience, the x64 version will deploy a 32-bit (x86) operating system, if need be.

ADK for Windows 10 installing on Windows Server 2012 R2

Now, MDT is set up on a server but it cannot do anything yet. There is much more configuration necessary to get to a working imaging and deployment solution. The first part is to create a deployment share. Everything MDT does is from within one or more deployment shares. Since MDT is very similar to a dedicated file server which shares Windows images and applications, it is best to use a very large storage space for the deployment share. I tried to set up a deployment share on a separate DFS path from the server’s own file system, but it did not work. Windows PE couldn’t find that deployment share during a deployment task sequence. For testing, a 1TB volume was more that sufficient for test and low-level production use. I’d split the 1TB volume into two partitions, one for the operating system, and the other for MDT’s deployment shares.

Should I dedicate an entire server or VM to MDT? It really depends on how much use is planned for it. Even if MDT is used to create and pull custom images of Windows which contain only the bare minimums necessary to create a usable, working Windows install, those images will start to take up space. Use as a traditional file server in addition to MDT is practical, but there may be performance deficits during times of peak imaging. YMMV…

Another important thing to note is that at this point, before the MDT config is set up, make sure the host name for the server is set to the desired name. Windows PE uses the server’s host name in the UNC path to connect to the deployment share during an imaging task. If the server is renamed, post MDT-config, those changes will NOT propagate to the deployment shares. It is not that much of a big deal to modify the deployment share to use the new name, but it is a hassle and best avoided.

To create a deployment share, open up the MDT Deployment Workbench as an administrative user on the server. It might even be a great idea to pin a shortcut to the Deployment Workbench to the task bar or desktop. The deployment workbench is divided into two sections, the Information Center, and the Deployment Shares. Choose the lower-half of the window, and right-click Deployment Shares and choose “New Deployment Share.” A wizard will appear, walking you through the creation process.

The first part of the wizard is to establish the local file path for the new deployment share. The default is “C:\DeploymentShare.” I would make this on a volume that is not shared with the operating system and that has plenty of space available. The new share can be named anything, but it cannot and should not ever be renamed. What name is chosen here is what will be for that share for it’s duration. Since I’m just testing here, I’ll go with the default.

The next step establishes the new deployment share’s share name, which is just the chosen name of the folder with a dollar sign ($) appended. In this example, the share name is “DeploymentShare$.” This share must be freely available on the network to clients that will be imaged with MDT. As stated before, the name of this share should never be changed once it is established.

After that, the next step is to give the new share a descriptive name. Again, this can be anything. If multiple deployment shares will exist on the same server, this name will be used to differentiate them in the Deployment Workbench. Be succinct and descriptive.

The Options page prompts for information that will form the basis of the deployment share’s configuration file, CustomSettings.ini. Any setting chosen here can be changed later on by editing that file. Usually, the defaults are fine for starters.

The next screen is a summary of the options chosen up to this point. The opportunity to go back and change anything is available here. Once this the wizard has advanced past this screen, the option to go back is no longer available. Make sure everything is as desired and proceed. The wizard will create the share and upon a successful completion will present it in the Deployment Workbench.

The new deployment share in the Deployment Workbench

Despite being created, the new deployment share cannot do anything yet. In order for it to become functional, the new deployment share needs one or more operating system images, applications to deploy at the time of imaging (optional), drivers for the deployments, and task sequences to coordinate the deployment process. The deployment share is divided into several folders, each named after it’s intended function. A right-click to any of those folders will provide the option to add content to those folders. Sub-folders can be added under the main folders for further organization. It is a good idea to divide your operating systems folder by the OS being used, the drivers folder by the manufacturer and model of computer holding the drivers. It doesn’t have to be done that way, but organization provides further opportunities for customization down the road.

The deployment share is controlled by a configuration file, a text file called “CustomSettings.ini.” The file resides in the deployment share’s folder, in the Control folder. CustomSettings.ini (CS) can be accessed easily by right-clicking the deployment share in the Deployment Workbench and choosing “Properties” and selecting the “Rules” tab.

A default CustomSettings.ini in the deployment share properties.

A default CustomSetting.ini in the deployment share properties.

Bootstrap.ini is a configuration file that is placed on the Windows PE volume when the deployment share is updated. Some of the configuration changes made to a deployment share are incorporated into Windows PE once the deployment share is updated. Upon update, the Windows PE volumes are created with the Bootstrap.ini file, drivers and any other selected options. The deployment share need only be updated when drivers are added/removed from the deployment share, and changes made to the Bootstrap.ini file. To update the share, right-click it’s folder in the Deployment Workbench and choose “Update Deployment Share.” The first update will take a while to complete as all of the drivers, or just the selection preset, are added to Windows PE. After that, the Windows PE ISO is only updated with the most recent changes made to the deployment share, unless the share (Windows PE) has been selected to be completely rebuilt.

Jason Watkins

10/30/2015

The next step is located here.

Note: Microsoft has a great series of Technet articles on how to deploy Windows 10 with MDT. The information contained in this post is a much simpler version of that information.

CampusPress/EduBlogs

Posted on October 9, 2015 by jasonrw

Hello,

Welcome!

For years, I have blogged on SAS’ OpenScholar platform, where I kept info regarding IT how-to’s and general information. EduBlogs/CampusPress is a new platform, being considered, so I asked to kick the tires and try it out.

My OpenScholar site can be found here.

I’ll follow-up shortly with more tech how-to’s and observations.

Hello world!