Computer Enterprise: January 2011

31 Jan 2011

What’s New in Windows Firewall with Advanced Security in Windows Server 2008 R2 and Windows 7

The Windows Firewall has come a long way since it was first introduced in Windows XP and Windows Server 2003 SP2. In fact, with the Windows Firewall with Advanced Security, there's no reason to even use a 3rd party firewall, although some administrators may prefer to do so for specific features or purposes. The Windows Firewall with Advanced Security (WFAS) has everything you need to create a secure networking configuration. In addition, the new WFAS adds to the firewall features and includes Connection Security Rules, which are IPsec rules that make it easier than ever to create secure IPsec connections between clients and servers, and from servers to server, on your network.

In this article, we'll go over some of the new and cool WFAS features that are included in Windows Server 2008 R2 and Windows 7.

Assign Different Firewall Profiles to Each NIC

In the Windows Firewall of the past, you could only have one firewall profile can be active at a time. If a computer is connected to more than one network, then the profile that had the most restrictive rules was applied to all NICs. The Public profile was the most restrictive, then the Private profile, and finally the Domain profile. This could cause problems by unnecessarily restricting access on domain and private networks.

Now this works as it should: each NIC is assigned its own profile. Traffic sent to or arriving from each network is processed according to the rules that are appropriate for the NIC that connects to each network.

Party Down with Dozens of Firewalls

WFAS is a lot more than just a simple host-based firewall. In addition to the firewall, it includes:

IPsec connection security rules
Network service hardening
Boot time filters
Firewall filters
Stealth filters

In the past, turning off the firewall meant also disabling all of the other services the Windows firewall provided. That meant that if you installed a different firewall that didn't provided all the services Windows firewall does, you lost those Windows firewall services (and possibly exposed the system to threats). Now when another host-based firewall is installed, the firewall's installer can disable components of the Windows Firewall that conflict. Other Windows Firewall services remain enabled.

Got Intermediate CAs? No Problem!

In the past, the connection security rules only used certificates issued by a root Certification Authority. You can now use certificates issued by intermediate CAs for your IPsec based Connection Security Rules.

Not Everyone Needs to Show His Papers

You can now create firewall rules that specify exceptions to the authorized list. This allows you to create firewall rules that say "everyone except a, b, and c" can access the host. Traffic from computers or users you specify in the exception list is blocked even though traffic from all other members of the authorized list are permitted. You can also create rules for outgoing traffic specifying authorized computers and exceptions to the authorized list.

Use the GUI to Configure Ports and Protocols for Connection Security Rules

Now you can use the MMC to create Connection Security Rules that specify port numbers or protocols. Only network traffic to or from the specified ports, or using the specified protocol, are subject to the IPsec requirements of the connection security rule. In the past you had to go to the "dark place" and use the netsh command to create these rules. Why would you want to live in a 1960s command line world when you have a cool and useful GUI? Now you don't have to!

Configure Firewall Rules that Support an Entire Range of TCP or UDP Ports

Now you can configure rules that include ranges of port numbers. For example, you can apply a rule that uses ports 5000 through 5010. You can also use port ranges in Connection Security Rules that specify authentication exemption.

The Windows Firewall Now "B" Suite!

Connection Security Rules now support the "Suite B" set of algorithms that are defined in RFC 4869. In the past you had to drive yourself nuts trying to create Suite B rules by using the netsh tool. This is great news for all of those admins who had been afraid that the "soul of Windows" was fading away into a Linux like command line nightmare (a.k.a. PowerHell). Don't get me wrong; the command line is great for certain tasks, and some folks prefer to do most of their work there. But others like Windows specifically because of its graphical interface, and I like having both options.

Authenticate While Making the Network Guys Happy at the Same Time

You can now create Connection Security Rules that enable IPsec authentication but with no Encapsulating Security Payload (ESP) or Authenticated Header (AH) protection on the data packets. That's right! You get authentication without encryption. This makes authentication possible when the network guys spaz out and tell you that you can't use ESP or AH because they put the company in hock by paying inflated prices for network IDS device that no one ever looks at. This new feature allows you to authenticate with the connection attempt, but there is no IPsec encryption, so the IDS can see everything moving over the wire.

Get IPsec Protection for Mobile Devices

Now you can get IPsec protection even when you can't predict what the IP address of both sides of the connection will be. In the past, you couldn't create IPsec rules for situations when one of the hosts would be assigned a dynamic IP address.

IPsec Tunnel Mode Gets a Boost

Now you can configure IPsec tunnel mode to allow both authenticated and authorized computers and users to establish a tunnel to your IPsec gateway. This is something that DirectAccess takes advantage of to allow both user and computer authentication for the infrastructure and intranet tunnels.

You can create tunnel-mode rules that define authentication that can authenticate a computer or user. Then the computer or user account is compared to the authorized list and then the tunnel is established and data can be exchanged if the user or computer is authorized. If the account is not authorized, then the connection fails. You can also specify exceptions, which allows you to create "everyone except UserA" rules in the console. One limitation is that Tunnel-mode authorization only works for inbound tunnels.

What's the Diffie (Hellman) with AuthIP?

Authenticated IP (AuthIP) is used instead of IKEwhen you create rules that have settings that are not supported by IKEv1. AuthIP uses the secret generated by the authentication method requested. For example, if you use Kerberos V5 authentication, then the Kerberos secret is used instead of the secret generated by a Diffie-Hellman exchange. However, you might want to use Diffie-Hellman. If so, now you can require that Diffie-Hellman be used in all IPsec main mode negotiations, even when AuthIP is used for authentication.

Use different Diffie-Hellman algorithms in main mode proposals

In Windows Vista and Windows Server 2008, you can specify only one Diffie-Hellman algorithm that is used in all IPsec proposals. This restricted you to ensuring that all computers in your organization used the same single Diffie-Hellman algorithm for IPsec negotiations. Starting with Windows 7 and Windows Server 2008 R2, you can specify a different Diffie-Hellman algorithm for each main mode proposal that you create.

Feeling the Love for IPv6 Transition Protocols

Sure, there's Teredo and 6to4, but those are so yesterday. How about something new and improved and created by Microsoft? That's what you get with IPv6 over HTTPS, also known as IP-HTTPS. IP-HTTPS is a new IPv6 transition technology that embeds IPv6 packets inside an HTTPS header. IP-HTTPS allows IPv6 traffic to move over an IPv4 Internet and performs a function similar to Teredo and 6to4. However, unlike Teredo, you don't have to open a special port on the firewall to allow access to IP-HTTPS, since everyone knows that TCP port 443 is the universal firewall bypass port.

However, you can still use Teredo. Like IP-HTTPS, Teredo is a tunneling protocol that attaches an IPv4 header onto IPv6 packets. For a Windows Firewall inbound rule, you can set the UDP port to Edge Traversal instead of a specific port number to have Windows Firewall automatically recognize and handle the connection appropriately.

Don't Encapsulate Unless you Have To

In the past, when network traffic that was IPsec protected was sent through an IPsec tunnel, it was wrapped in an IPsec and IP header. That's a lot of headers! Now when you want to configure a tunnel-mode rule, network traffic that is already IPsec protected will be exempted from the tunnel, and it moves to the tunnel endpoint without additional encapsulation.

Get a Clear View of Firewall Events in the Viewer

In the past, all firewall events were considered "audit"events, and were generated only if the appropriate audit category was enabled. Now some of these events are considered "operational" events, and appear in the Event Viewer without having to be enabled first. They appear under Applications and Service Logs \ Microsoft \ Windows \ Windows Firewall with Advanced Security. This makes it a lot easier to troubleshoot any number of firewall related scenarios.

The Windows Firewall just keeps getting better and better! In this article, we went over a number of new and improved features included in the Windows 7 and Windows Server 2008 R2 firewall. If you already know the Windows Firewall with Advanced Security, you're aware of the power you get with this built in host-based firewall. If you're new to the Windows Firewall with Advanced Security, then you should be getting the impression that the built in firewall included with Windows is all you need, and there is often no reason why you would need to install a third-party firewall (which frequently creates a situation where you have system instability and finger pointing). Also, keep in mind that the Windows Firewall with Advanced Security is much more than just a firewall. Its main duty outside of host-based firewall is its responsibility for IPsec connections, which depend on Connection Security Rules.

Top 10 Reasons to Upgrade

It has been a long time since we have seen a new version of Windows Server. It is hard to believe that it has been five years since Windows Server 2003 was released. Well this year we can stop waiting. Windows Server 2008 went RTM this month and now we all have access to the final bits. It has been a long time coming and Microsoft has put a great amount of work into Windows Server 2008 to make it the best Windows ever.

Thousands of changes have been made in Windows Server 2008 compared to Windows Server 2003. Some are very small, but some are quite significant. But the question on everyone's mind is what does Windows Server 2008 provide to make it a worthwhile upgrade? That is the focus in this article.

There are far too many changes for me to cover in a single article, so I have selected those features and capabilities that I think make Windows Server 2008 a worthwhile upgrade. Other people will look at the changes in Windows Server 2008 and think that I should have mentioned some of the other changes. That is fair, but here I am going to talk about the big changes, the changes that will make your life better and hopefully also make your users happier.

Here is my list of what I think makes Windows Server 2008 great and a worthwhile upgrade from Windows Server 2003:

Server Manager and the Advanced Event Viewer
Server Core
Terminal Services Gateway
Terminal Services RemoteApps
Native IPv6 support
Read Only Domain Controllers
Hyper-V
Network Access Protection (NAP)
Secure Sockets Tunneling Protocol (SSTP)
The Windows Advanced Firewall and Policy-based QoS

Server Manager and the Advanced Event Viewer

Windows Server 2008 includes an entirely new management interface known as the Server Manager. The Server Manager is a one stop shop for configuring, managing, and monitoring the server. This is not like the Server Manager's you might have used in the past; this one actually works and its one that you will use everyday when managing your Windows Server 2008 machines.

Figure 1

In the Server Manager, you can install Server Roles (such as DNS, DHCP, Active Directory) and Role services (such as Terminal Services Gateway and RRAS). When the Server Roles and Role Services are installed, the MMC consoles for these services are installed in the Server Manager. You no longer need to create your own custom MMCs!

The Server Manager also exposes the new and improved Event Viewer. This is not your father's old event viewer with just System, Security and Application nodes. Windows Server 2008 Event Viewer provides you with Event Logs you can use. There are the usual Windows Event Logs: Application, Security, and System. But now you have the ability to see Events for all applications and services installed on the computer. In addition, you can create Custom Views of the Event Logs, so that you can create your own containers for Events based on filters that you choose.

Figure 2

One of the new Event Log features that I like the most is the ability to Subscribe to Events on other machines on the network. This allows you to collect Event Log data from other machines, based on filters that you provide. In this way, you can configure filters for Critical Events for the most important servers on your network. While lacking the sophistication of a full fledged monitoring solution like System Center Operations Manager, it is a very nice built in monitoring solution for those companies that do not want to shell out for SCOM.

Server Core

Windows Server 2008 can be installed in one of two ways: full installation or server core. The Server Core installation installs a subset of binaries that are required to get the core operating system running. No optional services are installed or enabled. There is no user interface other than the command line. There is no Windows Explorer shell, and all configuration must be done locally at the command line, or remotely using the MMC console or the new Windows Remote Shell (WinRS) remote management application (similar to SSH).

The goal of server core is not to make it more difficult to manage (although it is to a certain extent, because many tasks must be done from the command line and cannot be done remotely from an MMC console). The actual goal of Server Core is to reduce the overall attack surface and to reduce the number of updates required on the server. Since most of the Windows security updates often involve services and applications that you do not even use (like Windows Media Player or Internet Explorer) on a server, you do not need to update these components. And with the greatly reduced number of applications and services that run on server core, the attack surface is definitely reduced.

Server core runs a limited number of Server Roles, so you have to make sure that the server role you are interested in is supported by a server core installation. Also, some of the Server Roles are not fully supported, such as the Web Server role. Server Core does not support .NET managed code, and therefore you will not be able to run the IIS console as a remote MMC. This creates a serious management headache because all IIS configuration on a server core machine must be done at the command line using appcmd.exe. If you are an Apache admin, you will be quite happy. If you are a part time IIS admin, you will probably want to wait on server core.

Server core is definitely a step in the right direction. However, at this time I would consider it a 1.0 release. I am sure the goals of server core were to reduce the attack surface and reduce update requirements, not to make it hard to manage. I expect future updates to Windows Server 2008 will make it easier to manage and allow it to live up to full expectations.

Terminal Services Gateway

One of the impediments to fully deploying Terminal Services for remote access users was the fact that a great many administrators did not trust the authentication sequence and the level of encryption of the RDP tunnels. Another problem encountered was the fact that many firewalls at remote locations did not allow outbound TCP 3389. Microsoft has solved these problems by introducing Terminal Services Gateway in Windows Server 2008.

Terminal Services Gateway is a type of SSL VPN, in the same way that RPC/HTTP for Outlook access to Exchange Server is an SSL VPN. The SSL VPN type is that of an application protocol proxy. Terminal Services Gateway works with the RDP 6.0+ client to allow encapsulated RDP connections to the TS Gateway computer.

The RDP client actually encapsulates the RDP protocol in two other protocols. First, the RDP protocol is encapsulated in an RPC header, and then it is encapsulated a second time using an encrypted HTTP header (SSL). The protocol used to connect to the TS Gateway is actually RDP/RPC/HTTP. Microsoft most likely did this so that they could use the existing RPC/HTTP code they already had for their RPC/HTTP proxy. When the connection reaches the TS Gateway machine, the TS Gateway removes the RPC and HTTP headers and forwards the RDP connections to the appropriate Terminal Server or Remote Desktop computer.

The figure below shows the interface for creating a Connection Authorization Policy or CAP. CAPs are used to determine which users can access resources through this TS Gateway computer. The dialog box in the figure shows the configuration interface for binding a certificate to the TS Gateway site so that secure SSL connections are allowed.

Figure 3

Terminal Services Gateway also supports Smart Card authentication and you also have the option to enforce NAP client access controls. Terminal Services Gateway is definitely one of the major reasons to upgrade to Windows Server 2008.

Terminal Services RemoteApps

The goal of every security admin is to reach least privilege for every user. That is especially true for remote access connections. Security admins like myself lose sleep at night thinking about providing full remote desktop connections to non-administrative users. All it takes is the compromise of one user's credentials by a dedicated hacker and that hacker has a full desktop environment under his control to compromise your network. That is a scary thought.

But do your users really need full access to a desktop? Or do they only need access to the applications on the desktop? Most likely, they just need access to the applications and data. In that case, Windows Server 2008 provides you with a solution called Terminal Services RemoteApp. Terminal Services RemoteApp allows you to provide access only to specific applications over the RDP channel. In that way, users cannot get into trouble with a full desktop, and if a hacker compromises that user's credentials, all the hacker has is an application, which has a much lower attack surface than a full desktop.

TS RemoteApps is very flexible. You can control which apps the users can access and how they access the apps on their own computers. TS Remote Apps together with TS Gateway make the Windows Server 2008 Terminal Server a must have for any company interested in a secure RDP based remote access solution.

The figure below shows the main page in the TS RemoteApp Manager console. Setting up TS RemoteApps is quite easy and you will be up and running in very little time.

Figure 4

The figure below shows the icon on the user's desktop that will launch the RemoteApp. In the Properties dialog box you can see that the link is configured to start an .rdp file that allows specific access to the application.

Figure 5

Native IPv6 support

Windows Server 2008 is the first version of Windows Server that has native IPv6 support as part of a single IP stack. In previous versions of Windows before Vista, IPv6 support was done in parallel with IPv4, and there was no integrated support for IPv6 included in network infrastructure services such as DNS and DHCP. That is no longer the case and now IPv6 is tightly woven into the Windows Server 2008 networking stack and infrastructure services.

In the figure below you can see that the Windows Server 2008 DNS now supports IPv6. You can create Quad A (AAAA) records and you can also create IPv6 reverse lookup zones.

Figure 6

The DHCP service has also been updated to support IPv6. In the figure below you can see that I have created a DHCP scope for Unique Local addresses.

Figure 7

The figure below shows that you can configure network interfaces to use static IPv6 addresses, or have them use DHCP to obtain IP addressing information.

Figure 8

Windows Server 2008 RRAS servers acting as routers can be configured as IPv6 routers and provide information in the routing advertisement messages regarding what prefix information clients can use, and whether or not they should use stateful addressing information from DHCP servers as well.

Windows Server 2008 also supports IPv6 transition technologies, such as ISATAP, 6to4 and Teredo. Any Windows Server 2008 computer can be configured as an ISATAP router by using the Netsh command line interface.

Read Only Domain Controllers

With the proliferation of branch offices in many organizations, many recognized the problem regarding authentication. Branch offices are often provisioned with a domain controller that users can authenticate to a local DC rather than having to go over a slow, or even downed, WAN link, which could cause authentication failures and inability to access even local resources.

The solution was to put domain controllers in the branch offices. While this solved the initial problem of authentication, it introduced a security problem. Since most branch offices do not have the same level of IT expertise as the main office, and most definitely do not have the same level of physical security as the main office, the branch office domain controller became a very weak link in the entire Active Directory infrastructure. Changes made by inexpert users at the branch office could have effects throughout the organization and if the DC at the branch office was stolen, it could potentially compromise all accounts in the organization.

The Windows Server 2008 solution is the Read Only Domain Controller (RODC). An RODC contains a read only copy of the Active Directory database, and the only account information stored on the RODC are for accounts at the branch office. Since no changes to the Active Directory can be made on an RODC, there is no fear that an inexpert user will make adverse changes to the Active Directory. And since there are typically no administrative users at the branch office, there is relatively little risk that the RODC at the branch office will contain admin users accounts that could be compromised in the event that the RODC is stolen.

RODCs can also be configured to cache only certain accounts. And in the event that the RODC is stolen, a list of cached user accounts on the RODC is available to the Active Directory admin at the main office. This allows the Active Directory admin to disable or reset the credentials on these accounts from the main office.

Hyper-V

Hyper-V is the Windows Server 2008 hypervisor that allows you to run virtual machines on Windows Server 2008 computers. Hyper-V replaces Virtual Server 2005 and is an integrated part of the operating system, which comes to you at no additional cost. The final bits for Hyper-V are not yet available, so I am going to reserve judgment on Hyper-V at this time. But, from what I have seen so far, I am very impressed with what they have done with Windows Server Virtualization. If you are looking for a no cost virtualization solution, then an upgrade to Windows Server 2008 is a good choice for you.

Network Access Protection (NAP)

Network Access Protection allows you to control access from all computers who connect to your network. According to Microsoft, Network Access Protection (NAP) is not so much a security methodology as it is a client health mechanism. NAP allows you to create policies that set a minimum state of client health before that computer is allowed to connect to other computers on the network.

NAP depends on a Windows Server 2008 infrastructure. You will need a Windows Server 2008 Network Policy Server to store your health policies. There are several ways you can control access to the network: IPsec restrictions, DHCP restrictions, 801.x restrictions and VPN restrictions. Hosts that do not meet the security configuration requirements are not allowed on the network using any of these methods. However, NAP does allow you to create quarantine networks that the non-compliant hosts can connect to in order to remediate themselves. Once the NAP client software detects that the machine is in compliance, it can send that information to the NAP server side components which will then inform the NAP client that it is OK to connect to the network.

NAP is an extremely powerful method for access control to your network, and it is something that we have been waiting for since it was announced sometime in late 2003, early 2004. While it took almost five years to get NAP to us, it has been well worth the wait. Many network admins consider NAP the primary reason for upgrading to Windows Server 2008. I would have a hard time arguing with these admins.

Secure Socket Tunneling Protocol (SSTP)

The Secure Socket Tunneling Protocol (SSTP) is a true SSL VPN. What I mean by "true" SSL VPN is that SSTP provides full network level VPN access to the corporate network in the same way that the PPTP and L2TP/IPSec protocols provide. However, the advantage with SSTP is that unlike PPTP and L2TP/IPSec, you do not have to worry about firewalls blocking outbound access to your SSTP connections.

SSTP is essentially PPP/SSL. Because the PPP connections are wrapped in a secure HTTP header (SSL), SSTP can pass through any firewall or Web proxy device that allows outbound SSL. No longer will you have to field calls from users at hotels and conference centers who complain that the firewalls in their locations will not allow them to VPN into the network. Another nice thing about SSTP is that you do not have to allow outbound access to SSTP connections just because you allow outbound SSL. There is a value in the CONNECT header that you can configure on your ISA Firewall or other application layer inspection firewall that will allow you to block SSTP connections while allowing other SSL connections.

SSTP is going to make your life a lot easier for remote access VPN connections. I would upgrade to Windows Server 2008 just for SSTP access.

Figure 9

Windows Advanced Firewall and Policy Based QoS

Windows Vista users will recognize the Windows Advanced Firewall. Now you get the same benefits Vista users have with Windows Server 2008. What is even better is that you can use Group Policy in Windows Server 2008 comprehensive centralized management of the Windows Advanced Firewall. If you have not used the Vista firewall yet, you are in for a treat. The Windows Advanced Firewall included with Vista and Windows Server 2008 allows you fine tuned inbound and outbound access control. The outbound access control was the missing piece with the Windows XP firewall. Now you have control on outbound connections so that if you detected on your firewalls that hosts are infected with a worm aimed at a certain port or collection of ports, you can block those ports on each host centrally through group policy.

The figure below shows the New Inbound Rule Wizard. The Wizard, which you can use in the Group Policy Management console, allows you to very easily configure inbound rules. There is also an outbound rule wizard that allows you to block outbound connections, you can control based on UDP or TCP ports, ICMP message types, or you can block on a per-application basis.

Figure 10

One of the most impressive features of the Windows Firewall is how it has simplified the creation of IPsec policies. In the past, setting up IPsec policies was a bit of a hit or miss situation. You would go through the wizards and hope that you had everything set up right. That is no longer the case with Windows Advanced Firewall. The figure below shows the easy to use New Connection Security Rule Wizard that makes it a simple affair to create IPsec domain isolation policies, authentication exemption policies, server to server IPsec connections and IPsec tunnels. The Windows Advanced Firewall has changed setting up IPsec policies from a dreaded event to something I actually look forward to doing. Give it a try, I think you'll like it.

Figure 11

Another major improvement in Windows Server 2008 is centralized QoS policy management through Group Policy. Previous versions of Windows included a QoS feature, but since it really was not based on standards, not many people (if anyone) every used it. Windows Server 2008 changes the game by introducing a new Policy-based QoS feature that you will actually be able to use right out of the box.

There are two ways you can implement QoS polices – you can hard code throughput values or you can take advantage of Differentiated Services Code Point (DSCP) values that are configured on your network routers. DSCP is an industry standard method for implementing QoS on corporate networks. However, even if you do not have DSCP enabled routers, or even if you do not use DSCP, you can still set policies so that the local hosts enforce bandwidth controls on TCP or UDP ports, or on specific applications.

The figure below shows a QoS policy that throttles the SMTP protocol on destination port TCP 25. You can select which hosts this policy applies to. For example, you would not want to throttle your SMTP server, but for hosts on your network, you might want to limit the rate of their SMTP traffic. In this way, you can control how much spam infected computers can send before you discover that the machines have been exploited.

Figure 12

Customizing the Default User Profile in Windows 7 (Part 4)

In the previous three articles of this series we have learned a seven-step process for customizing the default user profile in Windows 7:

Create a Task Sequence for Deploying your Reference Build
Create a Task Sequence for Sysprepping and Capturing your Reference Build
Customize the Reference Build using Unattend.xml
Deploy and Verify the Partially Customized Reference Build
Further Customize the Reference Build Manually
Sysprep and Capture the Fully Customized Reference Build
Verify All Customizations Made to the Default User Profile

It's important to realize that the whole process above of customizing a master installation of Windows 7 and deploying it to target computers for verifying such customizations can be done within a virtual environment such as a Hyper-V system. Doing so makes it easy to quickly customize the default user profile and test each customization before deploying your customized master image to physical computers.

Now when we walked through how to use the above default user profile customization process in the last three articles of this series, we tried making five customizations automatically (by configuring the Unattend.xml file for the MDT 2010 task sequence we used for deploying the customized master installation to target computers) and five customizations manually (by making direct changes to the desktop of our master installation before we used MDT 2010 to sysprep and capture an image of the installation).

When we tried verifying our customizations by deploying the customized master image to a target computer, creating a new local user account based on the default user profile, and logging on using this new user account, we discovered that two of the ten customizations we made didn't "take" on the target system. These two failed customizations were:

Specify a home page for Internet Explorer (we tried using the answer file to do this)
Pin a shortcut for Remote Desktop Connection to the Taskbar (we tried doing this one manually)

So the questions arises, were these two customization failures just flukes (aberrations) or are there some aspects of the default user profile in Windows 7 that simply can't be customized?

Issue #1: Configuring the IE Home Page

I checked with the MDT team at Microsoft concerning the first issue and received two replies. First, even with ordinary "clean" installations where the default user profile had not been customized on the master installation, they reported they have seen some cases where the IE home page value specified in the task sequence Unattend.xml file being overwritten during first logon on the target computer but have "never found a cause for that" so this particular issue may simply be a bug in MDT that hasn't been ironed out yet. One person suggested that this issue might be related to an IE update marked as needing configuration by Active Setup during next logon, but at this point there seems to be no clear answer to why this issue happens in some cases and not in others. If any readers have further insight into this issue, please feel free to contact me through my website www.mtit.com thanks.

Fortunately there are several workarounds for this issue. First, if you want to force users to use a particular home page for IE on their corporate users, you can use the following Group Policy setting to do this:

Disable changing home page settings

This policy setting is found under this location in the Group Policy tree:

User Configuration\Policies\Administrative Templates\Windows Components\Internet Explorer

Figure 1: Enforcing a home page for users using Group Policy.

Alternatively, if you just want to configure an IE home page for users but allow them to change this setting later if they desire, you can do this by creating a new Group Policy Preferences setting for Internet Explorer 8 and specifying a home page using this preference setting. To do this, right-click on User Configuration\Preferences\Control Panel Settings\Internet Settings and select New | Internet Explorer 8 and then in the Internet Explorer 8 Properties dialog that appears type the URL of the home page as shown here:

Figure 2: Configuring (but not enforcing) a home page for users using Group Policy Preferences.

Issue #2: to the Taskbar

Concerning the second issue, in order to customize your master installation by items to the taskbar, you must do this by editing unattend.xml instead of doing it manually. Let's see how to do this using the procedure outlined in the previous articles in this series.Pinning Items

In the Deployment Workbench, begin by opening the properties of the task sequence you are using to deploy your master installation. Then select the OS Info tab of the task sequence properties and click Edit Unattend.xml to use Windows SIM to open the answer file associated with this task sequence. (You can refer back to figures 8 and 9 of the first article in this series if you need to).

Now, in the Windows Image pane of Windows SIM, expand Components, expand Microsoft-Windows-Shell-Setup. Then right-click on the TaskbarLinks component and add it to the oobeSystem configuration pass as shown here:

Figure 3: Adding the TaskbarLinks setting to the oobeSystem pass.

Doing this, will add TaskbarLinks configuration settings to the oobeSystem section of your answer file. Now click in the empty box to the right of the Link0 setting in the TaskbarLinks Properties pane and enter the following path to the box:

%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\accessories\remote desktop connection.lnk

Here's what you should now see in Windows SIM:

Figure 4: Adding a shortcut for Remote Desktop Connection to the taskbar of the Public user profile.

What the above steps accomplish is to place a shortcut to Remote Desktop Connection on the taskbar of the Public user profile, which is found under C:\Users and has some its contents—such as Desktop, Taskbar and Start Menu—automatically merged with other user profiles on the computer. (In Windows XP, this user profile was known as the All Users profile and shared a similar function.)

Tip:
To verify that you entered the correct path, point to the Link0 setting and you'll see a tooltip that should look like this:

Figure 5: The tooltip verifies that we entered the correct path.

Now save the changes you made to your answer file and then use MDT to deploy your customized master image to a computer. When the install finishes, you'll be logged on as Administrator and you should see a shortcut to Remote Desktop Connection on the taskbar:

Figure 6: Shortcut to RDC on the taskbar of the master installation.

Next, use MDT to sysprep your customized master installation, capture its image, and upload the captured image to the Captures folder of your deployment share. Then import the captured image into the Operating Systems folder (or a subfolder of this folder) of your deployment share. Then create a task sequence (or modify an existing one) to deploy the imported image to target computers. Now when you use this task sequence to deploy your customized, sysprepped, captured and imported master installation to a target computer, you will be automatically logged on as Administrator. At that point, simply create a new local user on the deployed computer and verify that a shortcut for Remote Desktop Connection is pinned to the taskbar:

Figure 7: The customization worked.

Note that figure 4 above only shows settings for pinning three shortcuts to the taskbar i.e. Link0, Link1 and Link2. This is a limitation of using the above method—customizing the taskbar of the default user profile is limited to pinning no more than three shortcuts. You can read more about this approach in this post on the Ask The Core Team blog. If you need to pin more than three items to the taskbar, you'll need to use a scripted solution such as this one by The Deployment Guys.

Customizing the Default User Profile in Windows 7 (Part 3)

In the previous article of this series we began the process of customizing the default user profile in Windows 7. So far we've completed the following steps:

Create a Task Sequence for Deploying your Reference Build
Create a Task Sequence for Sysprepping and Capturing your Reference Build
Customize the Reference Build using Unattend.xml
Deploy and Verify the Partially Customized Reference Build
Further Customize the Reference Build Manually
Sysprep and Capture the Fully Customized Reference Build

We will now conclude the process of customizing the default user profile by performing the following seventh and final step:

Verify All Customizations Made to the Default User Profile

To perform this final step, we need to do the following five things:

Import our captured image into the Deployment Workbench
Create a new task sequence for deploying the imported captured image. This new task sequence will be based on the Standard Client Task Sequence template
Modify the Unattend.xml file for this new task sequence so that the CopyProfile setting has the value True
Deploy the captured image to a target system using this new task sequence
Create a new local user account on the target system and then check whether the ten customizations we've made have been successfully applied to the default user profile from which new local user accounts are generated

Import the captured image into the Deployment Workbench

We'll begin by importing our captured, sysprepped and customized Windows 7 operating system image into the MDT 2010 Deployment Workbench. To keep our imported images logically separated from other OS images, I've created a subfolder called Customized_Images beneath the Operating Systems folder of my deployment share. Then I right-click on Customized_Images and select Import Operating System:

Figure 1: Step 1 of importing the captured, sysprepped and customized image into the Deployment Workbench.
On the OS Type page of the Import Operating System Wizard, select the Custom Image file option:

Figure 2: Step 2 of importing the captured, sysprepped and customized image into the Deployment Workbench.
Browse to select the captured, sysprepped and customized Windows 7 image, which should be in the Captures folder of your deployment share:

Figure 3: Step 3 of importing the captured, sysprepped and customized image into the Deployment Workbench.
Leave the first option selected on the Setup page:

Figure 4: Step 4 of importing the captured, sysprepped and customized image into the Deployment Workbench.
We'll accept the name the wizard proposes for the destination directory that will be created for storing this image:

Figure 5: Step 5 of importing the captured, sysprepped and customized image into the Deployment Workbench.
Clicking Next begins the image import process:

Figure 6: Step 6 of importing the captured, sysprepped and customized image into the Deployment Workbench.
Once the import process is finished, you should see the imported image in the Customized_Images folder as shown here:

Figure 7: The captured, sysprepped and customized image of Windows 7 has been imported.
Before we can deploy the imported image to a target system for verification, we need to create a new task sequence for performing the deployment. We will do this next.

Create a task sequence for deploying the captured image

To create a new task sequence we can use to deploy the imported, captured, sysprepped and customized Windows 7 image, we begin by right-clicking on the Task Sequences folder in our deployment share and selecting New Task Sequence. This launches the New Task Sequence Wizard, and on the General Settings we need to specify a name and ID for our new task sequence:

Figure 8: Step 1 of creating a task sequence for deploying the captured, customized image.
Choose the Standard Client Task Sequence as the template for your new task sequence:

Figure 9: Step 2 of creating a task sequence for deploying the captured, customized image.
On the Select OS wizard page, select the imported image, which is found in the Customized_Images folder:

Figure 10: Step 3 of creating a task sequence for deploying the captured, customized image.
Continue through the remaining steps of the wizard until your new task sequence has been created.

Set CopyProfile to True in the Unattend.xml file

In MDT, each task sequence has an answer file (unattend.xml) associated with it. To ensure that the customizations we made to the default user profile of our imported, captured, sysprepped and customized image are properly deployed to the default user profile of a target system, we need to edit the unattend.xml file of our task sequence and make sure that the CopyProfile setting is set to True. The reason for this is given in the Unattend.chm help file included in the Windows AIK 2.0 and is described as follows: "The CopyProfile setting enables you to customize a user profile and use it as the default user profile. Windows uses the default user profile as a template to assign a profile to each new user."
To do this, right-click on your new task sequence in Deployment Workbench and select Properties to open the properties sheet of the task sequence:

Figure 11: Opening the properties of the task sequence.
The first time you do this, MDT needs to generate a catalog for the imported image. To do this, MDT first mounts the image and this may take a few minutes:

Figure 12: Opening the properties of the task sequence can take a few minutes.
Once the task sequence properties are open, select the OS Info tab:

Figure 13: The OS Info tab of the task sequence properties.
Now click the Edit Unattend.xml button on the OS Info tab. This opens the answer file for this task sequence in Windows System Image Manager (Windows SIM). Expand the specialize pass section of the answer file and select the Microsoft-Windows-Shell-Setup component, then in the Properties task pane change the CopyProfile setting to True as shown here:

Figure 14: Set the CopyProfile setting to True.
Click the Save button on the toolbar of Windows SIM, then close Windows SIM, and close the task sequence properties.

Use the task sequence to deploy the captured image to a target system

Now we're going to use our task sequence to deploy our imported, captured, sysprepped and customized Windows 7 image to a target computer. To do this, boot a bare-metal target system (or a new virtual machine) using the Lite Touch .iso file (the file LiteTouchPE_x64.iso found in the Boot folder of your deployment share). When the Windows Deployment Wizard appears, walk through its pages, being sure to select the task sequence you created above:

Figure 15: Deploying the customized image to a target system using LTI.
When MDT finishes deploying the customized image to the target system, you will be automatically logged on to the system using the default local Administrator account:

Figure 16: MDT automatically logs you on as local Administrator after a LTI deployment.
Tip: See my article Deploying Windows 7 - Part 6: Lite Touch using MDT 2010 and the other articles in my Deploying Windows 7 series here on WindowsNetworking.com if you need to learn more about performing Lite Touch Installation (LTI) deployments using MDT 2010.

Create a new local user on the target system and verify the default profile customizations

We have now customized the default user profile of a Windows 7 using two methods: by specifying answer file (unattend.xml) settings and by performing some manual customizations of our master installation. From the first article in this series, here again is the list of customizations we performed using an answer file:

Disable the Internet Explorer First Run Wizard.
Specify a home page for Internet Explorer.
Configure Windows Error Reporting (WER) so that collected data is automatically uploaded to Microsoft with no user interaction required.
Enable the Games built-in feature.
Prevent the XPS Viewer application from being installed.

And from the second article in this series, here again is a list of customization we performed manually:

Pin a shortcut for Windows Remote Assistance to the Start menu.
Pin a shortcut for Remote Desktop Connection to the Taskbar.
Change the default view of the Documents library from Details to Content.
Change the Control Panel default view from Category to Small Icons.
Change the Desktop Background from the default picture to solid light green.

We then sysprepped our customized master installation, captured an image of it, uploaded the image to our deployment share, and used MDT 2010 to deploy the customized image to a target computer. Let's now see if all our customizations worked.
If everything went as planned, the ten customizations we made on our master image should now have been applied to the default user profile on our target computer. In Windows 7, the default user profile is stored in a hidden folder named Default found under C:\Users. This default profile is never loaded and is copied as a template when creating a new local user account on the computer.
Tip: For more information about user profiles in Windows 7, see Chapter 15 of the Windows 7 Resource Kit from Microsoft Press. And for updates to this Resource Kit, see the Unofficial Support Site for the Windows 7 Resource Kit which is maintained by me.
So let's create a new local user account on our newly deployed target computer and see which of our ten customizations were applied. To create a new local user account, begin by typing new user in the Start menu search box:

Figure 17: Step 1 of creating a new local user account based on the customized default user profile.
In the search resources, click Create Standard User Account, and then type a name for the new account and select Standard User:

Figure 18: Step 2 of creating a new local user account based on the customized default user profile.
After you click Create Account, you will see a tile for the new local user account you just created:

Figure 19: The new local user account named Bob has been created.
Clicking the Start button shows that a shortcut for Windows Remote Assistance has been pinned to the Start menu (customization #6 above). Note however that there is no shortcut for Remote Desktop Connection pinned to the taskbar, so customization #7 didn't carry through our default profile customization process:

Figure 20: Customization #6 worked but not customization #7.
Clicking the Internet Explorer tile on the taskbar opens IE without launching the Internet Explorer First Run Wizard (customization #1) but instead of the expected home page of www.mtit.com we just get a blank page instead (customization #2):

Figure 21: Customization #1 worked but not customization #2.
Next, open the Action Center, click Change Action Center Settings, and then click Problem Reporting Settings. The result is shown below and confirms that customization #3 worked as expected:

Figure 22: Customization #3 worked
Next, click Start, then Programs, and then Games. As you can see below, games were installed, so customization #4 worked too:

Figure 23: Customization #4 worked
Next, type turn in the Start menu search box and then in the search results click Turn Windows Features On or Off. At this point a UAC prompt is displayed because Bob is a standard user, not an admin:

Figure 24: A UAC prompt is displayed when Bob tries to turn Windows features on or off.
After providing Bob with the credentials of the local Administrator account on the computer, the Windows Features dialog is displayed and shows that the XPS Viewer has not been installed (customization #5):

Figure 25: Customization #5 worked
Next, open the Documents library and click the More Options control on the toolbar. As you can see below, the default view for this folder is Content, which tells us that customization #8 worked:

Figure 26: Customization #8 worked
As you have probably noticed by now, the desktop background is green, so customization #10 was applied as well. Finally, opening Control Panel shows that the default view is Small Icons, so customization #9 worked as well:

Figure 27: Customization #9 worked
So it looks like all the customizations we made to our default user profile were applied, except these two:

Specify a home page for Internet Explorer (we tried using the answer file to do this)
Pin a shortcut for Remote Desktop Connection to the Taskbar (we tried doing this one manually)