Windows Server 2008: Top 10 in Windows Server 2008 R2

#10 Migration Tools: Starting off my Top 10 countdown are the migration tools available for Windows 2008 R2. Okay, so who gets excited about migration tools? Considering Windows 2008 R2 comes as a 64-bit only operating system and there’s no inplace upgrade path from 32-bit to 64-bit, the release of Windows 2008 R2 requires tools to help organizations “migrate” server to server than just shove in a CD and do an inplace upgrade. Because of that, Microsoft made some GREAT tools (and for any org than plans to migrate from physical Windows 2003 hardware to virtualized Windows 2008 R2 guest images, this is the PERFECT way to go from physical to virtual!!!) Go to http://www.microsoft.com/migration for a link to the various migration tools. There are tools that help you migrate fileservers (including files and ACLs), tools that help you migrate RRAS servers to 2008 R2, print server migration tools shifting your printers and print queues to 2008 R2. My favorite migration tool is the DHCP migration tool that migrates not only scopes, but also LEASES from old Windows DHCP servers to Windows 2008 R2 servers! (do you realize what that means? You can migrate a DHCP server in the middle of a day, carry over DHCP leases without having to expire out leases from the old server to get DHCP activated on a new server! (sorry, we were really excited when this tool came out, and to this day, I still get excited about sharing this!!!))

#9 Active Directory 2008 R2: Number 9 on my list are updates to Active Directory. Gotta start off by saying that no one really “has” to migrate to AD/2008 or AD/2008 R2 for any of the current products, so things like Exchange 2010, SharePoint 2010, etc do NOT require AD/2008 (or 2008 R2). We have a LOT of customers who are happily running AD/2003 in Native Mode with all of the latest and greatest products running. However, for those who want enhancements in AD, the biggies in 2008 R2 are the Recycle Bin (effectively allows you to simply recover deleted objects in AD, so if you fat finger delete a user object, accidentally overwrite an AD group, simply go to the recycle bin and undelete stuff…). Also in AD/2008 R2 is Offline Domain Join which allows you to pre-stage create a computer account in AD, dump an XML file and then when you install Windows 7 on the computer you can run a DJoin command on the Windows 7 and “join” the domain on that Win7 computer without the Win7 computer even being attached to the network! That way you can build systems in the lab and “join them” to AD without actually / physically connecting the computers to AD. Okay, another geek moment, but this is great when we’re prestaging systems to roll out in another site or domain and we don’t even need to be physically at or physically connected to that domain… Oh, and something that I’m still excited about that’s in AD/2008 is Fine Grain Password Policies. In AD/2003 you could only have 1 password policy per domain (upper case, complex password, change every 30-days, etc had to be the SAME for everyone in the domain). With Fine Grain Passwords added to AD/2008 (and carried over to AD/2008 R2) you can now set password policies “per group” so you can have folks in HR or Accounting change their passwords every 20-days to please the regulators, and field support and sales people can change their passwords say ever 60-days or something. All done by groups, really slick!!!



#8 Remote Server Manager: Alright, #8 on my Top 10 countdown is the ability to remotely manage other Windows 2008 R2 servers using the Server Manager tool. With Windows 2008 you had this really great tool “Server Manager” that allowed you to Add Roles, Features, Administer the servers, etc from a single console, however it was ONLY for the system you were on, so you had to constantly Remote Desktop into other servers. Now with Windows 2008 R2 servers you can remotely access Server Manager on other systems. So just sit at one console and reach into other servers in your network to do day to day administrative tasks!



#7 Direct Access: Okay, DirectAccess, probably gets my award for “most innovative technology” in Windows 7 client and Windows 2008 R2 server and would have been closer to #1 in my countdown if it weren’t so complicated to implement. So DirectAccess is a technology that effectively does away with VPNs. Just like RPC/HTTPS (Outlook Anywhere) eliminated the need to VPN from Outlook to Exchange for your email a few years ago, DirectAccess does away with VPNs by giving you access to “everything else” on your network like your F> and K> drive shares, http:// SharePoint shares, accounting software, CRM software, etc. Basically “anything” you normally have access to from a VPN, you can now access “natively” from a Windows 7 client. DirectAccess leverages IPSec policies and Certificates to “automatically” tunnel a Windows 7 client into the network. Effectively a client that has DirectAccess configured can simply turn on their laptop or desktop computer, get an Internet connection, and over encrypted IPSec re-establish normal network connections, but “outside” the network. AND, your internal network doesn’t have all be Windows 2008 R2, just a single server in the DMZ needs to be running Windows 2008 R2 as a “proxy” that effectively encrypts communications between the client and this one 2008 R2 server. Everything else “inside” your network can be just plain old TCP networking like Windows 2003, SharePoint, Linux, etc… Okay, so here’s the catch, the client systems need to be Windows 7 (not a biggie, a lot of orgs have already started their migration to Win7 clients). You need to enable IPv6 on the 2008 R2 proxy/gateway server and IPv6 on all Win7 clients (also not a biggie because it’s on by default since Win2008 and Vista, although you need to now understand how IPv6 works to do the proper addressing, so that’s a learning experience to figure out). You need to be running Microsoft Certification Authority (CA), which for many orgs is also not a big deal as they’ve been running Microsoft’s CA for a while, however if you haven’t setup Microsoft’s CA, kind of familiar with Auto-enrollment of certificates to automatically push out certs using AD, this is something new for you to learn. If you’re already doing Auto-enrollment, you’re set! And then IPSec and split DNS, this is the technical pieces that everyone gets wrong and Microsoft’s whitepaper guide on DA is not very helpful. We took time writing this portion of the chapter of my Windows 2008 R2 book as once you get this working, then DA actually works! So, a REALLY slick technology once you get it working. I’d recommend any hardcore techie to throw this in your lab to fiddle with, it’s a great technology to understand and ultimately implement!

#6 SConfig in ServerCore: So for #6 on my countdown is SConfig.exe in ServerCore. So how many of you actually installed Microsoft’s GUI-less ServerCore when it came out in Windows 2008? Who enjoyed the “net user administrator…”, “netdom rename computer…”, “netdom join..” commands to even get a ServerCore system assigned an IP address and joined to a domain before you could even do anything? It was a pain and the reason that a lot of people gave up on ServerCore. So with Windows 2008 R2, Microsoft came up with a utility called “Sconfig.exe” that you run after you install ServerCore. Now from the DOS prompt thing, you just type Sconfig and a “menu” (text based) shows up on screen. You walk the menu to name your server, give it an IP address, domain a domain, and most importantly set it so you can run Remote Server Manager (see #8 on my list) to remotely manage the server. So you can now have a simple menu to get the basics going, and then remote into the system and use the Server Manager GUI to do the rest! Where I can count the number of ServerCore systems we installed in Windows 2008 on one hand, I can now say we’re deploying a couple dozen ServerCore systems a week these days because of these new tools built-in to Windows 2008 R2!

#5 Improvements in Group Policy Management: Okay, most of this is Windows 2008 stuff on the Group Policies, but never the less, what Microsoft has done with Group Policies in Windows 2008 (and 2008 R2) has been awesome, so it landed in the #5 spot on my Top 10! So the minute you launch the Group Policy Management Console (GPMC) you’ll notice not just the Computer Configuration container and the User Configuration container, but under the Computer and User containers are “Policies” and “Preferences”. The Policies container is the same container that has been in AD all along where you have containers for Account Policies, Windows Settings, Administrative Tools, Security, etc. But under the “Preferences” is a whole new set of “views” to policies. For some 1000+ policies, instead of more text based “descriptions” of stuff, there’s a GUI for you to “see” a user Control Panel type stuff where you can click through the GUI to “set” settings. When you set the settings and click OK, you’re effectively creating the group policy. So for things like Internet Explorer settings, you just click the checkbox or option on screen, and those settings are set. Or you can do drive mappings through a GUI, or set display settings through a GUI. This whole Preferences area REALLY makes setting policies easier. It’s just like you are in Control Panel on your workstation, but instead what you choose are set for the “policy” for the managed systems…

 

#4 Clustering of Print Servers and DHCP: We’re at #4 on my countdown and it’s about clustering. So with Windows 2008 R2, you can cluster everything like you used to (fileservers, app servers, etc) but they’ve added a whole bunch of other things to cluster. My 2 favorite new clustered features are clustering print servers and DHCP servers… So how many times have you had a print server printer service stop and all of the print queues on the system go offline. A simple restart of the service gets you going again, but now you have hundreds of print jobs backed up… I would have never taken 2 hardware systems and cluster print services, that was overkill of hardware, but with virtualization, heck yeah, put a print server as a guest session one physical host, and cluster it with a guest session on another physical host. I now have full redundancy on a print service with effectively zero downtime! And the other cluster service that has been really slick is clustering DHCP. Do you know for the past 20 years we’ve been doing DHCP “split scopes” the whole 80/20 or 60/40 split scope across servers, which really wasn’t fault tolerance, it was moreso just minimizing our risk that when a DHCP server went offline that we were still able to limp along. Now with virtual guest sessions, I can CLUSTER the DHCP servers with 100% of my IP addresses. I have two servers issuing IP addresses in perfect unison. If I lose one server, I have another DHCP server continuing exactly where I left off. I can failover and patch/update a server back and forth. This completely changes (and drastically improves) something as simple as DHCP…



#3 Remote Desktop Services: Number 3 on my list is Remote Desktop Services, or RDS, which used to be called Terminal Services. Every administrator has used Terminal Services / Remote Desktop to reach into a server to remotely administer / manage a server, and a number of orgs have used Terminal Services and Citrix for our client systems. With Windows 2008 R2, we’ve really found orgs can get rid of Citrix and just use the straight features out of 2008 R2 because why did people buy Citrix? It was because Citrix provided Single Sign-on (so you didn’t have to enter in your password to logon to Citrix), better remote printing offered by Citrix, high availability offered in Citrix, and the ability to just drop an application icon on a user’s desktop and give remote access to an “application” and not have to do the full Remote Desktop with the 2nd start button and everything. With Windows 2008 R2 (actually with Windows 2008) ALL of these features are native to Remote Desktop Services out of the box. So as long as your client system is running XP SP3 or higher, you get the single sign-on so you never have to type a logon/password to get access to a RDS session. You can run RDS “RemoteApp” to simply launch an application right from your client system. Also added in Windows 2008 R2 is Virtual Desktop Infrastructure (VDI) which provides you the ability to give personal desktop sessions (like Hyper-V guest sessions) to individual users for a full desktop experience. All of this is something you used to have to go to 2 or 3 other vendors for these features (Citrix and VMware) that are now included out of the box in Windows 2008 R2. Check these features out!



#2 Hyper-V R2: Alright, down to #2 and Hyper-V server virtualization hits my #2 spot… What can I say, just a couple years ago 100% of my server virtualization business was VMware, they dominated the whole virtualization world and in just over a year, Microsoft released Hyper-V with Windows 2008 and then updated Hyper-V with Windows 2008 R2 to include not only what VMware has in their VI3 and their newly released vSphere 4, but Microsoft now gives it all away out of the box in Windows 2008 R2. If money matters to you, what organizations used to buy ESX, V/Motion, and now VSphere for, you get it all in Windows 2008 R2. In side by side comparisons, server virtualization is server virtualization whether it’s VMware or Hyper-V R2, you can run guest sessions (lots of them on a 32gb 8core server (12-15 easily)), you can take snapshots so before you patch or update a guest session, just take a snapshot and if the update screws up your application, just rollback to the snapshot. If you have a problem with any Microsoft product being virtualized (Exchange 2010, SharePoint 2007, System Center, etc) it’s the same company / same support call to get Exchange support as it is Hyper-V virtualization support. And with Hyper-V R2, you can now “cluster” Hyper-V host servers and move guest sessions across Hyper-V hosts, AND not only move them around for disaster recovery, you can do them LIVE in the middle of the day without dropping a client session state in what Microsoft called “Live Migration” (and VMware calls V/Motion that you pay lots of extra $$ for). You just right click a guest session and “Live Migrate” the guest session to another server in the middle of the day to evacuate a problemsome host, or maybe do load balancing of hosts, or as part of your process to move images so you can patch and update a host. End of the day, VMware is far from 100% of our virtualization business and actually in just a couple years is now at par with Microsoft and now Microsoft Hyper-V makes up 50% of our virtualization business…

#1 Stability and Reliability: Okay, not a specific feature or function, but my #1 on Windows 2008 R2 is that it just plain works! This is the first operating system we’ve deployed well over a year in beta in full blown production environments without issues, and our experience since the product RTM’d has been just as solid. No issues, no surprises, this one has been a keeper and because of that, Stability and Reliability of Windows Server 2008 R2 and Windows 7 puts this in my #1 spot!

- Win Server 2008: BranchCache and DirectAccess

While the unwashed masses finally have their first peek at Windows Server 2008 R2 and Windows 7, the chosen ones have been working with the release candidate (RC) code since May and the release to manufacturing (RTM) version since August. Whichever group you’re in, you probably have been inundated with hype. Maybe you were invited to a Windows 7 preview “house party,” like me, for example. (My son-in-law hosted one, but only because he wanted the software free from Microsoft.) Even if you were spared that major hype, you couldn’t have avoided each of the many media reports extolling or questioning the new features of these products, both of which are from a new code tree and constitute new ISATAPISATOSes.

BranchCache and DirectAccess, arguably the crown jewels of these releases, are worth your attention. With BranchCache, Microsoft aims to give branch employees the same experiences working with files as their peers at the corporate office. With DirectAccess, Microsoft targets remote users connecting to corporate networks via virtual private networks (VPNs).

As is typical with Microsoft, you only get the good stuff on the new products. In this case, you can only implement BranchCache DirectAccess to Windows 7 clients and 2008 R2 servers. Let’s take a deeper look at each of these new features.

BranchCache

BranchCache improves the branch office experience by caching commonly used files locally, either on a Windows Server 2008 R2 server or user workstations, rather than forcing users to access files via centrally located network shares. BranchCache is cool, but there are caveats.

IT can deploy BranchCache in Distributed Cache Mode or Hosted Cache Mode (see Figure 1). IT configures the mode via Group Policy, so using hosted mode at one office and distributed mode at another requires implementing two policies and planning organizational unit (OU) structures accordingly. Microsoft recommends deploying Distributed Cache Mode in sites of 50 or fewer clients, but it will depend on speed and bandwidth of the WAN link, as well as other factors. Distributed Cache Mode will require larger hard disks and perhaps memory and other resources, so at some point it will be more advantageous to use Hosted Cache Mode, especially if there’s an existing 2008 R2 server at the site. In addition, Distributed Cache Mode can only work on a local subnet. So if there are multiple subnets at a site, then a client on each subnet will have to cache the file for others on that subnet to download it. However, Hosted Cache Mode can serve multiple subnets at the site, so that would be another reason to choose Hosted Cache Mode.

Figure 1 A branch office can use BranchCache in either distributed or hosted modes.

In Distributed Cache Mode, no file server resides at the branch office. Instead, through policy, all user machines are BranchCache clients, that is, they all have the ability to cache documents that others in the branch site can download—if they’re the current version.

For example, let’s say that Caroline requests a document, Reports.docx from a BranchCache-enabled file server in the central site. BranchCache sends metadata describing the content of the file. Hashes in the metadata are then used to search for the content in the local subnet. If not found, a copy is cached on her computer’s local drive. Later in the day, Tyler needs to modify Reports.docx so he contacts the share on the main office file server to get a copy to edit. The file server returns the metadata, then the client searches for the content, which it finds on and downloads from Caroline’s computer. This is done securely using an encryption key derived from the hashes in the metadata. The next day, Abigail needs to modify that same document. The process is the same, but she’ll be opening the copy cached on Tyler’s computer. Again, the version information is kept at the server. Clients contact the server to determine if there is a copy of the latest version at their site.

This is one of three BranchCache scenarios that will come into play as users work with various documents. The other two are:

• A branch office worker asks the main office file server for a document that is not cached on a local computer. The user receives a copy, which is then cached locally.
• A branch office worker asks the file server for a document that’s cached in the local site, but the computer is turned off. The client obtains a new copy from the file server and caches it on his PC. Future requests lead to this the newest cached copy.

In each case, the documents also save to the main office file server. That way, if Caroline comes back and wants to access the document but Abigail’s computer, which now houses the latest version, is turned off, she will receive the document from the main office server.

With Hosted Cache Mode, IT configures a Windows 2008 R2 file server in the branch office with BranchCache by installing the BranchCache feature, and configuring a Group Policy to tell the clients to use Hosted Cache Mode. The procedure described for Distributed Cache Mode works the same here, but the files are cached on a locally configured BranchCache server rather than the users’ computers.

Note: the content metadata maintained by the file server in the central office site is sent to each client when a file is requested from a BranchCache-enabled server. This is used to determine if any local client or server (depending on which cache mode is used) has the most recent copy.

The BranchCache-enabled server at the branch site can be used for other purposes, such as a Web or Windows Server Update Services (WSUS) server. Special considerations must be made in these cases, and is described in the Microsoft BranchCache Deployment Guide and Microsoft BranchCache Early Adopter’s Guide.

BranchCache Configuration

To configure BranchCache, you’ll need to understand how Group Policy Objects (GPOs) work and how to configure them in your OU structure to affect the computers at each site. Remember that all servers involved in the BranchCache scenario must be Windows Server 2008 R2 and all clients Windows 7. Here’s the process:

Step 1. Install the BranchCache feature via Server Manager.

Step 2. If you’re using BranchCache on a file server you’ll need to install the File Services Role as well as BranchCache for remote files (see Figure 2).

Figure 2 A BranchCache installation requires enabling the File Services and BranchCache for remote files roles.

Step 3. Configure a BranchCache GPO. Go to Computer Configuration | Policies | Administrative Templates | Network | BranchCache. You will see five possible settings:

• Turn on BranchCache. This has to be enabled for all BranchCaching (see Figure 3). Note that enabling BranchCache without enabling Distributes or Hosted Cache mode policy settings causes the local Windows 7 client to cache files locally. This is useful if multiple users use one computer.
  

Figure 3 In the Group Policy Management Console, enable the BranchCache for branch office caching.

• Set BranchCache Distributed Cache Mode. This applies to all clients in the GPO.
• Set BranchCache Hosted Cache Mode. Specify a server to host the cache. These roles are mutually exclusive. Only one can be configured for the site.
• Configure BranchCache for network files. If not configured or disabled, this defines a latency threshold of 80ms. If the file request takes more than 80ms, then the file will go into cache. Enable this setting and change the latency value as desired.
• Set percentage of disk space used for client computer cache. This is set by default at 5 percent of the user’s disk. You’ll have to play with this to get the right amount for servicing the cache versus giving the user required space. This can be a problem if you have disk configurations that vary widely on size, as some will have greater cache capacity than others.

Step 4. Configure GPO setting “LanMan Server” in the BranchCache Policy. In the same area of the GPO in Step 3, go to the LanMan Server setting and look at the properties for “Hash Publication for BranchCache.” The three options are:

• Disallow hash publication on all shared folders.
• Allow hash publication for all shared folders.
• Allow hash publication only for shared folders on which BranchCache is enabled.

Servers that are running the File Services server role on 2008 R2 servers, which are desired to be BranchCache content servers, must also run the BranchCache for Network File Services role and hash publication must be enabled. BranchCache is also enabled individually on file shares. The hash publication can be enabled individually on a server (such as for a non-domain server configuration), or on groups of servers via Group Policy. Thus, BranchCache can be enabled on all shared folders, some shared folders or disabled entirely.

Step 5. Configure the GPO setting in Windows Firewall to allow inbound TCP port 80 (applied to the client computer).

Step 6. Once you’ve configured everything, and if the file share exists with the users’ files, go to Server Manager | File Services | Share and Storage Management. The center pane lists the shares. Right-click on the share and select Properties, then click Advanced. On the Caching tab, enable BranchCache (see Figure 4). Note: If the BranchCache option is unavailable, then the BranchCache feature wasn’t installed properly or the policy is set to disable, as noted previously.

Figure 4 Enable file sharing with BranchCache using Share and Storage Management controls.

BranchCache Client Configuration

By default all Windows 7 clients are enabled for BranchCache, meaning there is nothing to enable on the client itself. However, there are client-related steps that are required:

• Configure Firewall settings. While this was noted earlier, there are other requirements for Hosted Cache Mode. Refer to the BranchCache documents from Microsoft noted at the end of this article.
• Clients must be in an OU that contains a policy that enables BranchCache and defines which cache mode to be used. Again, refer to the documents at the end of this article for more detail.

BranchCache: The Good

Here’s what I like about BranchCache:

• It can use the Background Intelligent Transfer System (BITS) to enable file transfers in the background if the user is logged in, even if the application exits. This is a great feature for branch offices connected over slow links. Should a system restart be necessary, file transfer continues once that completes. For this to work, of course, applications must be written to take advantage of BITS.
• BranchCache is configurable via the Netsh command-line utility and is well-documented on TechNet’s BranchCache for Windows Server R2 site.
• You can monitor BranchCache performance through counters for the client, file server and cache host. Not only are these helpful for performance diagnosis, as far as I can tell, watching these counters is the only way to see if the client is really getting a cached copy.
• The BranchCache environment is controllable via Group Policy.

BranchCache: The Bad

BranchCache will certainly have its place, but beware these drawbacks:

• Because Distributed Cache Mode essentially turns every workstation into a file server, client machines hosting a lot of frequently accessed files could suffer performance hits. This will need some testing to determine actual impact.
• In some cases, clients may require additional disk space to allow for sufficient cache sizes.
• Caching clients will now be competing with peers for network resources.
• Delays may crop up during the initial caching process or when a file is not available in cache. Only Windows 7 clients and Windows Server 2008 R2 servers can participate, so a full rollout of this feature may take some time.

If you can justify putting a file server in the branch office, why not use Distributed File Shares (DFS)? Rather than messing around with cached files, you can use Distributed File System-Replication (DFS-R) to replicate the files and maintain a namespace with DFS. You may find advantages to caching the network files, and perhaps BranchCache will work on DFS shares. Or, perhaps you’ll find some performance boundary where the cache is more efficient than DFS-R. On the other hand, the impact on the server for BranchCache would be lower than a full-blown DFS configuration. The point is, you’ll have to study your needs, and examine the options available with BranchCache. Of course, each environment is different and what may cause problems in some branch offices won’t in others. There is no one right answer for all situations.

DirectAccess

With DirectAccess, Microsoft addresses the poor VPN experience users have had since Windows 2000, even with many improvements since the initial implementation. A DirectAccess-configured client can access an intranet site from a remote location without having to establish a VPN link manually. In addition, much to their delight, IT staffs can manage remote machines over an Internet connection rather than through the VPN. So if I’m working at home, connected to my company’s intranet, and the Internet link drops, the VPN will re-establish the connection when the Internet becomes available—without pestering me to reconnect and re-enter my credentials as I would have to do—often repeatedly—without DirectAccess.

In fact, from a user’s viewpoint, DirectAccess is invisible. When a user on an enabled client clicks on the intranet link, DirectAccess handles the connection and disconnection. Users do not have to open Connection Manager, enter their credentials, wait for the connection and so on.

While the remote connection is live, the user has a “split tunnel” configuration by default (see Figure 5). This enables simultaneous access to the intranet, the local network (for use of devices such as printers) and the Internet. In a typical VPN scenario without the split tunnel, connecting to the Internet means first hopping on the intranet and then passing through the corporate network gateway for connectivity. In addition, I have no access to my local network, although workarounds are possible. So again, DirectAccess is designed to give the remote user a more “in the office” experience than traditional VPN affords.

Figure 5 DirectAccess enables a split-tunnel configuration for simultaneous connectivity to the corporate network and Internet.

From IT’s perspective, once the computer is on the Internet (remember that DirectAccess is always enabled if it’s installed), patches, policies and other updates are easy—and secure via IPsec connections—to apply.

DirectAccess Requirements

In a basic DirectAccess configuration, the DirectAccess server is on the edge network, providing remote user connectivity to internal resources including the application servers, certificate authorities (CAs), the DNS and domain controllers (DCs). CAs and application servers must be configured to accept IPv6 traffic. Here are the essential components of a DirectAccess configuration:

• In the Active Directory Domain, DirectAccess clients will only be able to access Windows 2008 or 2008 R2 DCs.
• Group Policy definitions must enforce DirectAccess settings to:

Identify DirectAccess clients. Configure the Name Resolution Policy Table (NRPT). Remove the Intra-Site Automatic Tunneling Address Protocol (ISATAP) from the DNS global restriction list.

• The DirectAccess server must:

Be a member of the Active Directory Domain. Run on Windows Server 2008 R2. Have two network adapters configured (one for intranet and the other for Internet connectivity). Have two consecutive static IPv4 addresses externally resolvable.

• Be installed with DirectAccess management “feature” (via Server Manager), and setup wizard run for configuration.

• The IIS/Web server enables functionality that determines if intranet resources are reachable. Application servers must be configured to allow access by DirectAccess-enabled clients.
• For use with the required CA, install Active Directory Certificate Services and issue certificates for authentication.
• Either a native IPv6 network or transition technologies must be available throughout the intranet.
• Using IPsec policies for secure authentication and DirectAccess connection encryption, the client authenticates before the user logs on.
• You can find necessary firewall exceptions in the Microsoft DirectAccess Early Adopter’s Guide.

As you can see, DirectAccess is not for the faint of heart. The IPv6 requirement alone will undoubtedly raise concern—and require most organizations to implement transition technologies—but 2008 R2 does have the components. In addition, you have to enable security via a public key infrastructure (PKI), provide authentication services and set up IPv6 identification to application servers. Before running the DirectAccess setup wizard, you also have to configure the security groups, establish firewall policies, setup the DNS and complete a number of other prerequisites.

DirectAccess Server

The DirectAccess server performs a number of functions, defined through Server Manager’s DirectAccess setup wizard (see Figure 6).

Figure 6 Initiate DirectAccess setup through Server Manager.

The DirectAccess wizard performs four essential tasks. Through the wizard you will:

1. Identify clients to be DirectAccess-enabled. You can list security groups from other domains or forests here, if trusts are configured. You must define appropriate security groups prior to running the wizard.
2. Define connectivity and security (certificates) for the DirectAccess server. You will identify which network interface is on the Internet side and which connects to the intranet. Install the CA and create the certificates prior to running the DirectAccess setup wizard. In addition, define smartcard policy.
3. Identify the DNS, DC and, optionally, management and other infrastructure servers for use in the DirectAccess environment. You also must identify a highly available server as the network location server. The DirectAccess server can fill this role.
4. Identify the application servers configured to accept connections from DirectAccess clients. The default is no additional end-to-end authorization, but you can select IPsec policy-based security options.

DNS and the NRTP

As noted previously, DirectAccess clients can access the intranet directly. To enable this, you must implement the NRPT, which defines DNS servers per DNS namespace rather than per network interface. I think of this as the way conditional forwarding works on Windows 2003 and 2008 DNS servers, where you can define DNS namespaces with the appropriate IP address to connect to the server. NRPT allows a client to avoid normal DNS iteration and go directly to the DirectAccess server.

Here’s how the NRPT works (see Figure 7):

1. A name query request matches a configured namespace for the corporate intranet, pointing to the DirectAccess server.
2. The NRPT contains the IP address and the DirectAccess server’s Fully Qualified Domain Name (FQDN). When the IP address is used, the connection to the DNS server is encrypted for a secure connection.
3. When the FQDN is used, it must be resolved through the Internet and find the corporate DNS server.
4. If the client sends a name resolution request for a namespace not defined in the NRPT (such as www.microsoft.com), then it follows normal name resolution through the Internet
   

Figure 7 The NRPT enables definition of DNS servers per DNS namespace rather than per interface.

NRPT is configured during DirectAccess setup in the Infrastructure Server Setup page and the wizard fills in the IPv6 address of the DNS server. Name Resolution Policy, a new Group Policy setting for 2008 R2, defines specific policy settings such as IPsec, DNS server and how the name resolution fallback occurs when the namespace isn’t in the queried network. You’ll find this in Computer Configuration | Windows Settings | Name Resolution Policy (note, you must enter domain namespaces with a leading dot “.”—for example, .emea.corp.net).

You can expose NRPT contents using the Netsh command: Netsh name show policy.

This will show the namespaces defined.

Firewall Exclusions

Firewall exclusions will depend on how you implement the IPv6 network and if you use the transition technologies. In addition, any file or application servers the remote clients must connect to will need Windows Firewall configured appropriately. Figure 8 and Figure 9, below, show firewall exclusions for the firewall on the Internet and intranet sides of the DirectAccess server, respectively. Obviously you only need to set exclusions for technologies you are using. (Note that even though Figure 9 lists IPv4+NAT-PT, it’s not implemented by Windows 2008 R2.)

Figure 8 Firewall Settings for the Internet Firewall

Transition Technology	Protocol to Allow
Teredo	UDP 3544
6to4	IP Protocol 41
IP-HTTPS	TCP 443
Native IPv6	ICMPv6, Protocol 50

Figure 9 Firewall Settings for the Intranet Firewall

Protocol	IPv6 Technology
	ISATAP	Native IPv6	IPv4 + NAT-PT
Protocol 41	X
TCP		X	X
UDP		X	X
ICMPV6		X
All IPv6 connectivity		X
UDP 500 IKE/AuthIP		X	X

Connectivity - IPv6

Because IPv6 permits DirectAccess clients to maintain continuous connectivity to resources on the corporate network, they must all run the protocol. Even if you have a fully implemented IPv6 network, allowing remote connectivity may require use of a transition technology that would allow the DirectAccess client to connect to IPv4 resources by encapsulating IPv6 inside of IPv4 packets. These technologies include 6to4, IP-HTTPS and Teredo. ISATAP also is an encapsulation technology but is only used internally. I won’t go into detailed descriptions here, but Figure 10 shows basic connectivity options.

Figure 10 Preferred Connection Options for DirectAccess Clients

If the client is assigned a:	Preferred connectivity method:
Globally routable IPv6 address	Globally routable IPv6 address
Public IPv4 address	6to4
Private (NAT) IPv4 address	Teredo
If the client cannot connect using the above	IP-HTTPS

Source: Microsoft

On the intranet side, without native IPv6, DirectAccess permits use of ISATAP, which generates an IPv6 address from an IPv4 address and implements its own neighbor discovery. ISATAP allows DirectAccess clients to access resources on an IPv4 network. For example, when an ISATAP client boots, it must find an ISATAP router. It does this by issuing a DNS query for ISATAP.. So for Corp.net it would look for ISATAP.corp.net. Windows 2008 DNS implements GlobalQueryBlockList, an additional security feature that includes ISATAP by default. This causes it to ignore any ISATAP. request. Therefore, you must clear ISATAP from the list. Do this via the DNSCMD command or by making a registry entry.

At a command prompt, enter dnscmd /config /globalqueryblocklist wpad and press Enter. This will define the GlobalQueryBlockList as only having WPAD in it (thus removing ISATAP). You also may accomplish this by going to the registry key at

HKLM:\System\Current Control Set\Services\DNS\Parameters. Edit GlobalQueryBlockList and remove ISATAP.

You also can implement 6to4 individually on hosts or over an entire network and transmit IPv6 packets over an IPv4 network. Interestingly, if 6to4 is implemented for an entire network, it requires only one IPv4 address. It does not support traffic between IPv4 and IPv6-only hosts.

Teredo also provides IPv6 packets to be routed to IPv4 networks, but is used when the client is behind a Network Address Translation (NAT) server that is not configured for IPv6. It stores IPv6 packets in the IPv4 datagram that allows forwarding from the NAT.

Windows 7 and Server 2008 R2 have implemented a protocol called IP-HTTPS that tunnels IPv6 packets in an IPv4 HTTPS. While IP-HTTPS has poorer performance than the other protocols, you can add additional IP-HTTPS servers to improve performance somewhat. IP-HTTPS is a fairly easy protocol to enable to get the IPv6-over-IPv4 network connectivity to work.

When designing the DirectAccess client configuration, you can either use DNS and the NRPT to separate Internet and intranet traffic, or you can use something called Force Tunneling and force all traffic through the tunnel. Force Tunneling, which requires IP-HTTPS, is enabled via Group Policy setting Computer Configuration\Policies\Administrative Templates\Network\Network Connections\Route all traffic through the internal network. This policy would need to apply to the DirectAccess clients. I noted previously that DirectAccess clients can access local resources while connected to the intranet. This still holds true for IP-HTTPS clients, but if the user tries to access Internet sites, for example, it would be routed through the intranet.

Certainly the IPv6 requirement and complex configurations are downsides to DirectAccess, but those are easily outweighed by user experience improvements and ease of remote client management for IT.

Great Promise

The number of remote workers, be they at a branch, in a home office or on the road, is increasing. BranchOffice and DirectAccess hold great promise for branch office and other remote workers, and IT managers and administrators would be wise to investigate them. Neither of these will be a quick and easy setup, and there are a number of options and features that are available. In addition, these features will only work on Windows 7 clients and Windows Server 2008 R2 servers, so this will definitely impact an implementation timeline. IT managers and administrators would be wise to study the Microsoft documentation available and configure it in a test lab to ensure success.

- Win Server 2008 : Delete Files Permanently with SDelete

When you delete a file, Windows removes the index for the file and prevents the operating system from accessing the file’s contents. However, an attacker with direct access to the disk can still recover the file’s contents until it has been overwritten by another file—which might never happen. Similarly, files that have been EFS-encrypted leave behind the unencrypted contents of the file on the disk.

With the SDelete tool, which you can download for free, you can overwrite the contents of free space on your disk to prevent deleted or encrypted files from being recovered.

To use SDelete to overwrite deleted files on the C drive, run the following command:

sdelete -z C:

- Win Server 2008 : Use Built-In Tools to Create Partitions and Volumes

Windows Server 2008 simplifies the Disk Management user interface by using one set of dialog boxes and wizards for both partitions and volumes. The first three volumes on a basic drive are created automatically as primary partitions. If you try to create a fourth volume on a basic drive, the remaining free space on the drive is converted automatically to an extended partition with a logical drive of the size you designate by using the new volume feature it created in the extended partition. Any subsequent volumes are created in the extended partitions and logical drives automatically.

In Disk Management, you create partitions, logical drives, and simple volumes by following these steps:
1. In Disk Management’s Graphical View, right-click an unallocated or free area and then choose New Simple Volume. This starts the New Simple Volume Wizard. Read the Welcome page and then click Next.
2. The Specify Volume Size page specifies the minimum and maximum size for the volume in megabytes (MB) and lets you size the volume within these limits. Size the partition in MB in the Simple Volume Size field and then click Next.
3. On the Assign Drive Letter Or Path page, specify whether you want to assign a drive letter or path and then click Next. The following options are available:
Assign The Following Drive Letter Choose this option to assign a drive letter. Then select an available drive letter in the selection list provided. By default, Windows Server 2008 selects the lowest available drive letter and excludes reserved drive letters as well as those assigned to local disks or network drives.
Mount In The Following Empty NTFS Folder Choose this option to mount the partition in an empty NTFS folder. You must then type the path to an existing folder or click Browse to search for or create a folder to use.
Do Not Assign A Drive Letter Or Drive Path Choose this option if you want to create the partition without assigning a drive letter or path. If you later want the partition to be available for storage, you can assign a drive letter or path at that time.
Note You don’t have to assign volumes a drive letter or a path. A volume with no designators is considered to be unmounted and is for the most part unusable. An unmounted volume can be mounted by assigning a drive letter or a path at a later time.
4. On the Format Partition page, determine whether and how the volume should be formatted. If you want to format the volume, choose “Format This Volume With The Following Settings” and then configure the following options:
File System Sets the file system type as FAT, FAT32, or NTFS. NTFS is selected by default in most cases. If you create a file system as FAT or FAT32, you can later convert it to NTFS with the Convert utility. You can’t, however, convert NTFS partitions to FAT or FAT32.
Allocation Unit Size Sets the cluster size for the file system. This is the basic unit in which disk space is allocated. The default allocation unit size is based on the size of the volume and, by default, is set dynamically prior to formatting. To override this feature, you can set the allocation unit size to a specific value. If you use many small files, you might want to use a smaller cluster size, such as 512 or 1024 bytes. With these settings, small files use less disk space.
Volume Label Sets a text label for the partition. This label is the partition’s volume name and by default is set to New Volume. You can change the volume label at any time by right-clicking the volume in Windows Explorer, choosing Properties, and typing a new value in the Label field provided on the General tab.
Perform A Quick Format Tells Windows Server 2008 to format without checking the partition for errors. With large partitions, this option can save you a few minutes. However, it’s usually better to check for errors, which enables Disk Management to mark bad sectors on the disk and lock them out.
Enable File And Folder Compression Turns on compression for the disk. Built-in compression is available only for NTFS. Under NTFS, compression is transparent to users and compressed files can be accessed just like regular files. If you select this option, files and directories on this drive are compressed automatically.
5. Click Next, confirm your options, and click Finish.

- Win Server 2008: Create System Startup / Shutdown and User Logon / Logoff Scripts

With Windows Server 2008 you can configure four types of scripts:
Computer Startup Executed during startup
Computer Shutdown Executed prior to shutdown
User Logon Executed when a user logs on
User Logoff Executed when a user logs off

You can write scripts as command-shell batch scripts ending with the .bat or .cmd extension or as scripts that use the Windows Script Host (WSH). WSH is a feature of Windows Server 2008 that lets you use scripts written in a scripting language, such as VBScript, without needing to insert the script into a Web page. To provide a multipurpose scripting environment, WSH relies on scripting engines. A scripting engine is the component that defines the core syntax and structure of a particular scripting language.

Assigning Computer Startup and Shutdown Scripts
Computer startup and shutdown scripts are assigned as part of a group policy. In this way, all computers that are members of the site, domain, or organizational unit—or all three—execute scripts automatically when they’re booted or shut down.

To assign a computer startup or shutdown script, follow these steps:
1. For easy management, copy the scripts you want to use to the Machine\Scripts\Startup or Machine\Scripts\Shutdown folder for the related policy. Policies are stored in the %SystemRoot%\Sysvol\Domain\Policies folder on domain controllers.
2. In the GPMC, right-click the GPO for the site, domain, or organizational unit you want to work with and then select Edit. This opens the policy editor for the GPO.
3. In the Computer Configuration node, double-click the Windows Settings folder and then click Scripts.
4. To work with startup scripts, right-click Startup and then select Properties. To work with shutdown scripts, right-click Shutdown and then select Properties.
5. Click Show Files. If you copied the computer script to the correct location in the Policies folder, you should see the script.
6. Click Add to assign a script. This opens the Add A Script dialog box. In the Script Name field, type the name of the script you copied to the Machine\Scripts\Startup or the Machine\Scripts\Shutdown folder for the related policy. In the Script Parameters field, enter any command-line arguments to pass to the command-line script or parameters to pass to the scripting host for a WSH script. Repeat this step to add other scripts.
7. During startup or shutdown, scripts are executed in the order in which they’re listed in the Properties dialog box. Use the Up and Down buttons to reposition scripts as necessary.
8. If you want to edit the script name or parameters later, select the script in the Script For list and then click Edit.
9. To delete a script, select the script in the Script For list, and then click Remove.

Assigning User Logon and Logoff Scripts
You can assign user scripts in one of three ways:

• You can assign logon and logoff scripts as part of a group policy. In this way, all users who are members of the site, domain, or organizational unit—or all three—execute scripts automatically when they log on or log off.
• You can also assign logon scripts individually through the Active Directory Users And Computers console. In this way, you can assign each user or group a separate logon script.
• You can also assign individual logon scripts as scheduled tasks. You schedule tasks using the Scheduled Task Wizard.

To assign a logon or logoff script in a group policy, follow these steps:
1. For easy management, copy the scripts you want to use to the User\Scripts\Logon or the User\Scripts\Logoff folder for the related policy. Policies are stored in the %SystemRoot%\Sysvol\Domain\Policies folder on domain controllers.
2. In the GPMC, right-click the GPO for the site, domain, or organizational unit you want to work with and then select Edit. This opens the policy editor for the GPO.
3. Double-click the Windows Settings folder in the User Configuration node and then click Scripts.
4. To work with logon scripts, right-click Logon and then select Properties. To work with logoff scripts, right-click Logoff and then select Properties.
5. Click Show Files. If you copied the user script to the correct location in the Policies folder, you should see the script.
6. Click Add to assign a script. This opens the Add A Script dialog box. In the Script Name field, type the name of the script you copied to the User\Scripts\Logon or the User\Scripts\Logoff folder for the related policy. In the Script Parameter field, enter any command-line arguments to pass to the command-line script or parameters to pass to the scripting host for a WSH script. Repeat this step to add other scripts.
7. During logon or logoff, scripts are executed in the order in which they’re listed in the Properties dialog box. Use the Up and Down buttons to reposition scripts as necessary.
8. If you want to edit the script name or parameters later, select the script in the Script For list and then click Edit.
9. To delete a script, select the script in the Script For list, and then click Remove.

- Windows Server 2008 Server Core: Commands and Tools

Full server and server core installations are different when it comes to local console administration. With a full server installation, you have a UI that includes a full desktop environment for local console management of the server. With a core server installation, you have a minimal UI that includes a limited desktop environment for local console management of the server. This minimal interface includes:

• Windows Logon screen for logging on and logging off
• Notepad for editing files
• Regedit for managing the registry
• Task Manager for managing tasks and starting new tasks
• Command Prompt for administration via the command line

After you log on to a core-server installation, you have a limited desktop environment with an Administrator command prompt. You can use this command prompt for administration of the server. If you accidentally close the command prompt, you can start a new command prompt by following these steps:
1. Press Ctrl+Shift+Esc to display Task Manager.
2. On the Applications tab, click New Task.
3. In the Create New Task dialog box, type cmd in the Open field and then click OK.

You can start Notepad and Regedit directly from a command prompt by entering notepad.exeregedit.exe as appropriate. To open Control Panel, type intl.cpl.

At the command prompt, you’ll find that you have all the standard commands and command-line utilities available for managing the server. However, keep in mind that commands, utilities, and programs will only run if all of their dependencies are available in the core-server installation.

While core-server installations support a limited set of roles and role services, you can install most features. The key exceptions are those that depend on the .NET Framework. Because the Microsoft .NET Framework is not supported in the original implementation, you cannot add features such as Windows PowerShell. And you can use Terminal Services to manage a core-server installation remotely.

Here is an overview of key commands and utilities you’ll use for managing server core installations while logged on locally:
Control desk.cpl - View or set display settings.
Control intl.cpl - View or set regional and language options, including formats and the keyboard layout.
Control sysdm.cpl - View or set system properties.
Control timedate.cpl - View or set the date, time, and time zone.
Cscript slmgr.vbs –ato - Activate the operating system.
DiskRaid.exe - Configure software RAID.
ipconfig /all - List information about the computer’s IP address configuration.
NetDom RenameComputer - Set the server’s name and domain membership.
OCList.exe - List roles, role services, and features.
OCSetup.exe - Add or remove roles, role services, and features.
PNPUtil.exe - Install or update hardware device drivers.
Sc query type=driver - List installed device drivers.
Scregedit.wsf - Configure the operating system. Use the /cli parameter to list available configuration areas.
ServerWerOptin.exe - Configure Windows Error Reporting.
SystemInfo - List the system configuration details.
WEVUtil.exe - View and search event logs.
Wmic datafile where name=“FullFilePath” get version - List a file’s version.
Wmic nicconfig index=9 call enabledhcp - Set the computer to use dynamic IP addressing rather than static IP addressing.
Wmic nicconfig index=9 call enablestatic(“IPAddress”), (“SubnetMask”) - Set a computer’s static IP address and network mask.
Wmic nicconfig index=9 call setgateways(“GatewayIPAddress”) - Set or change the default gateway.
Wmic product get name /value “ - List installed MSI applications by name.
Wmic product where name=“Name” call uninstall - Uninstall an MSI application.
Wmic qfe list - List installed updates and hotfixes.
Wusa.exe PatchName.msu /quiet - Apply an update or hotfix to the operating system. or