MDT, Importing an Operating System

Posted on by

In order for MDT to do anything, it needs an operating system to capture or to deploy. MDT 2013 Update 1 will use operating system file from the Windows installation ISO, or captured from a custom installation. Either way, the file format for the operating system must be in Windows Image (WIM) format. Starting with Windows Vista, Microsoft switched to WIM format for the files on the original installation media (DVD or ISO). Windows 10 is no different.

To get started, the original installation image for the version of Windows to be deployed must be imported into MDT. For example, we’ll import Windows 10 Enterprise into MDT with the “Import Operating System wizard.” I like to organize the operating systems and other files by category.

Mount the operating system ISO, or insert the operating system DVD into the MDT server.

Open MDT, and navigate to the Operating Systems folder.

Right-click the operating systems folder and choose “New Folder.” Call it “Windows 10.” At this point you could create a sub-folder to Windows 10 after the bit strength of the operating system, x64 or x86, but since I only plan on dealing with 64-bit Windows 10 there is no need.

The new Windows folder under the operating systems folder in MDT.

The new Windows folder under the operating systems folder in MDT.

Right-click the new Windows 10 folder and choose “Import Operating System.” A wizard will appear, guiding the process.The first place determines what kind of image is being imported. Our example will import “Full set of source files.” The “Custom image files” is for a customized install of Windows captured as a WIM file.

Full set of source files is needed to start with MDT.

Full set of source files is needed to start with MDT.

Next, navigate to the drive that contains the source files that are to be imported into MDT. here, it is drive “E:\”

Navigate to the source directory where the operating system files are.

Navigate to the source directory where the operating system files are.

The next step asks for an operating system directory. The default is to take it from the title of the ISO. I added the word “ISO” to the end of the name, so it can be distinguished from other operating system files. This name is the name of the folder the operating system files will go into in the deployment share, under “Operating Systems.”

Give the target directory for the OS a descriptive name.

Give the target directory for the OS a descriptive name.

Continue through the summary, and finish importing the operating system into MDT. The import will take a few moments to complete. After the import is done, the new OS will be in the deployment console, under the name it was given.

The imported OS WIM in the deployment workbench.

The imported OS WIM in the deployment workbench.

 

With Windows 10 into MDT, we can create deployment tasks to install Windows 10 on computers and even capture it back after customization. That will be next.

 

Configure macOS for PennKey Authentication

Posted on by

PennKey logins allow any previously-allowed user within SAS, or the university, the ability to access a public computer without having a local user account on that computer or a domain user account. All Macs in the SAS Central Pool Classrooms use this type of authentication.

Mac OS X uses PennGroups and kerberos to facilitate PennKey authentication. The following procedure works on OS X versions 10.8.4 – 10.14.6

Requirements: access to PennNet, PennGroups LDAP account (ask jasonrw), administrative access to the target Mac OS X 10.8.4 – 10.14.6

UPDATE (1/31/21): Apple introduced lots of changes with macOS 10.15 “Catalina.” Some of these differences broke the manner in which we have traditionally configured PennKey authentication. The good news is that 10.13, 10.14 Macs, configured for PennKey authentication and upgraded to 10.15 continue to permit PennKey logins. The Bigfix fixlet, which configures PennKey authentication no longer works.

The same can be said for macOS 11 (10.16?) “Big Sur.” Upgraded PennKey Macs do continue to permit PennKey logins. The rub is that none of the configuration profiles installed onto macOS are accessible by PennKey users. Admin users are fine, but unprivileged PennKey users will get a barrage of admin authentication prompts which never end. Even if an admin username/password are provided, the prompts keep coming. At this point, Big Sur is not viable for use with PennKey authentication.

UPDATE (2/15/18): The EMS team has created an IEM (BigFix) fixlet which will do all of the following on any relevant Mac. As much fun as it has been going through motions of setting up this type of access manually, it is no longer required.

Note: This process modifies how OS X authenticates users each time they log in. Mistakes here could render the Mac unable to authenticate any user. It would not be a bad idea to make a backup of the target Mac prior to beginning this configuration procedure. I use Disk Utility for this purpose.

The first part of this involves modifying three configuration files that help set up kerberos authentication.

The FIRST part is to create a “krb5.conf” file on the target system, or download one from here or open up the terminal and create a new file, called krb5.conf, under /etc (sudo nano /etc/krb5.conf). Edit the file to match what is listed below.

The completed krb5.conf file

The completed krb5.conf file

The SECOND part is to setup the Mac OS X login window for kerberos authentication by modifying the preexisting “/etc/pam.d/authorization” file.

Again, from the Terminal and type sudo nano /etc/pam.d/authorization. Then, navigate to the first auth optional section and add the value“default_principal” to the end of the line, as shown below.

The /etc/pam.d/authorization file after modification.

The /etc/pam.d/authorization file after modification.

THIRD. Configure Open LDAP to ignore certificates by editing the preexisting “/etc/openldap/ldap.conf” file. From the Terminal, enter the command sudo nano /etc/openldap/ldap.conf. You will need to edit the line that reads TLS_REQCERT DEMAND and change DEMAND to never as shown below.

The modified ldap.conf file. Note the "never" change.

The modified ldap.conf file. Note the “never” change.

 

FOURTH, configure Directory Access. This is by far the most tricky part of the whole procedure. Steps have to be performed exactly as indicated or else PennKey authentication WILL NOT work.

Open the Directory utility, while logged-in as an admin user. Apple buries the Directory Utility in the Users applet in System Preferences.

Select LDAPv3 and then click the edit box below and a new window will appear. Click on New then click Manual then click Edit. Under the Connections tab, enter the information as shown in the box below.

  1. name the configuration PennGroups
  2. enter the server name penngroups.upenn.edu
  3. check the box Encrypt using SSL
The custom PennGroups configuration in the Directory Utility.

The custom PennGroups configuration in the Directory Utility.

 

The PennGroups account settings.

The PennGroups account settings.

Leave the rest at their defaults and then click on Search and Mappings tab at the top.

  1. In the drop down box next to Access this LDAPv3 server… select Custom
  2. Select the Default Attribute Types, then click Add, then select Record Types and highlight Users
  3. Select the Users record type you just added and click the Add button that is located under the right pane (Map to ‘any’ items in list)
  4. Add the value pennidTranslation and
  5. Set the Search base for the Users record type: ou=pennnames,dc=upenn,dc=edu and select Search in all subtrees as shown below.
The Search & Mappings settings.

The Search & Mappings settings.

Now comes the fun part, adding the attributes for the Users record type. They all have to be added and in the following order. The order must be correct and exact, or else none of this will work.

  1. AuthenticationAuthority
  2. NFSHomeDirectory
  3. PrimaryGroupID
  4. RealName
  5. RecordName
  6. UniqueID
  7. UserShell
 
Each one of these attributes has a certain value attached to it. The value is entered in the right-hand box, next to the attribute. The first is AuthenticationAuthority.
 
  1. AuthenticationAuthority = pennname
  2. NFSHomeDirectory = #/Users/$pennname$
  3. PrimaryGroupID = #20
  4. RealName = cn
  5. RecordName = pennname
  6. UniqueID = pennid
  7. UserShell = #/bin/bash
An example of one of the attribute settings that must be completed successfully.

An example of one of the attribute settings that must be completed successfully.

Almost done! Next, we have to configure directory authentication for the whole configuration. ISC would have had to provide the organization with a username and password for this part. Open the “Security” tab next to the “Search and Mappings” tab.

  1. Check the box to Use authentication when connecting
  2. Enter the Distinguished Name of the principal (service account) that has been setup (see the prerequisites) in the format uid=<principal>,ou=entities,dc=upenn,dc=edu
    for example:
    uid=mac-stuff/sas.upenn.edu,ou=entities,dc=upenn,dc=edu
  3. And enter the password for that account, as shown below. OK out of the PennGroups settings dialogs until you are back at the Directory Utility window.
Enter the UID for your organization with the password.

The security tab

OS X has to be told to check the directory each time a username and password is entered. Click on Search Policy at the top. Make sure you have selected the Authentication button and for the Search option, select Custom Path and then click the Plus (+) to add the LDAP directory, which should be available for you to select as shown below. Click Apply, and you are now finished!

 

The authentication path lists local account, then directory accounts are checked at log on.

The authentication path lists local account, then directory accounts are checked at log on.

Change the log on window for OS X to not show a list of users, but just the username and password dialog boxes, or else you will not be able to log on with a PennKey. Go into System Preferences \ Users & Groups \ Select the “Login Options” button and select “Name and password” radio button under the “Display login windows as:” section.

The Login Options under the Users & Groups applet.

The Login Options under the Users & Groups applet.

REBOOT and test a PennKey log on. There may be a red dot in the user name field stating network accounts are not available from the log on screen. That *should* go away with a few seconds after the Mac boots. If it does not, check the network connection to PennNet and try again.

 

I would also add a message to the login screen indicating that PennKey logins are supported in addition to local logins, and that domain logins may or may not be supported. Running the following command from the terminal or from an ARD Unix command will make such a change.

sudo defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "Please log in with your PennKey username and password."

Enjoy!
Jason Watkins
10/25/2016

MDT, Getting Started

Posted on by

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:

  1. 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).
  2. 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.
  3. 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

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.

New Deployment Share PathThe 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.

New Deployment Share OptionsThe 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.

Deployment Workbench Image

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 by

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!

Posted on by

Welcome to your brand new blog at SAS Sites.

To get started, simply log in, edit or delete this post and check out all the other options available to you.

For assistance, visit our comprehensive support site, check out our Edublogs User Guide guide or stop by The Edublogs Forums to chat with other edubloggers.

You can also subscribe to our brilliant free publication, The Edublogger, which is jammed with helpful tips, ideas and more.