Windows ITIS and Virtulization -AD LDS, AD RMS, AD FS--High availability, Citrix, Vmware

Hyper-V Live Migration: A Step-by-Step Guide

2011-06-08T21:12:00.000-07:00

Live migration is probably the most important technology that Microsoft has added to Hyper-V in Windows Server 2008 R2. It enables virtual machines (VMs) to be moved between Hyper-V hosts with no downtime. Using live migration, you can migrate all VMs off the Hyper-V host that needs maintenance, then migrate them back when the maintenance is done. In addition, live migration enables you to respond to high resource utilization periods by moving VMs to hosts with greater capacities, thereby enabling the VM to provide end users with high levels of performance even during busy periods.
Live migrations can be manually initiated, or if you have System Center Virtual Machine Manager 2008 R2 and System Center Operations Manager 2007, you can run automated live migrations in response to workload. You need to complete quite a few steps to set up two systems for live migration, and I’ll guide you through the process. First, I’ll explain how live migration works. Then I’ll cover some of the hardware and software prerequisites that must be in place. Finally, I’ll walk you through the important points of the Hyper-V and Failover Clustering configuration that must be performed to enable live migration.

How Live Migration Works

Live migration takes place between two Hyper-V hosts. Essentially, the VM memory is copied between Hyper-V hosts. After the memory is copied, the VM on the new host can access its virtual hard disk (VHD) files and continue to run. Both hosts access shared storage where the VM’s VHD files are stored. When you initiate a live migration, which Figure 1 shows, the following steps occur:

      1. A new VM configuration file is created on the target server.
      2. The source VM’s initial memory state is copied to the target.
      3. Changed memory pages on the source VM are tagged and copied to the target.
      4. This process continues until the number of changed pages is small.
      5. The VM is paused on the source node.
      6. The final memory state is copied from the source VM to the target.
      7. The VM is resumed on the target.
      8. An Address Resolution Protocol (ARP) is issued to update the network routing tables.

Requirements for Live Migration

On the hardware side, you need two x64 systems with compatible processors. It’s best if the host processors are identical, though it’s not required. However, they do need to be from the same processor manufacturer and family—you can’t perform a live migration when one host has an AMD processor and the other host has an Intel processor. Learn more about Hyper-V processor compatibility in the Microsoft white paper “Virtual Machine Processor Compatibility Mode.”
      In addition, each of the servers should be equipped with at least three NIC cards, running at 1GHz: one for external network connections, one for iSCSI storage connectivity, and one for node management. Ideally, you’d have another NIC dedicated to the live migration, but the live migration can also occur over the external network connection—it will just be a little slower. It’s important to note that if you’re implementing a server consolidation environment, you will want additional NICs for the network traffic of the VMs.
      On the software side, all the nodes that take part in live migration must have Server 2008 R2 x64 installed. This can be the Standard, Enterprise, or Datacenter editions. Live migration is also supported by the Hyper-V Server 2008 R2 product. In addition, the Hyper-V role and the Failover Cluster feature must be installed on all servers participating in live migration.
      You also need shared storage, which can be either an iSCSI SAN or a Fibre Channel SAN. In this example, I used an iSCSI SAN. Be aware that the iSCSI SAN must support the iSCSI-3 specifications, which includes the ability to create persistent reservations, something that live migration requires. Some open-source iSCSI targets such as OpenFiler don’t have that support at this time. If you’re looking to try this for a local test and don’t want to buy an expensive SAN, you might want to check out the free StarWind Server product at http://www.starwind.com/.

Failover Cluster Networking Configuration

Failover clustering is a requirement for live migration. You can live-migrate VMs only between the nodes in the failover cluster. The first step in creating a failover cluster is to configure the networking and storage. You can see an overview of the network configuration used to connect the Windows servers in the cluster to the external network and to the shared storage in Figure 2.

In Figure 2 the servers are using the network with the subnet of 192.168.100.xxx for client connections. The iSCSI SAN is running on an entirely separate physical network which was configured using the 192.168.0.xxx IP addresses. You can use different values for either of these IP address ranges. I selected these values to more clearly differentiate between the two networks. Ideally, you would also have additional NICs for management and an optional live migration connection, but these aren’t strictly required. Live migration can work with a minimum of two NICs in each server.

Deploying Network Load Balancing (NLB) and Virtual Machines on Windows Server 2008 R2

2011-06-08T21:05:00.000-07:00

In Hyper-V, the VM host prevents dynamic MAC address updates as an extra layer of security in the datacenter. This is because the VM may have full administrator rights, yet it may be untrusted in the datacenter, for example when the VM hosting is provided by an independent hosting company. In this scenario, we need to make sure that one VM cannot cause a DOS or information disclosure attack against another VM. If a VM is able to spoof its MAC address, then it can spoof the MAC addresses of other VMs and impact other VMs on that host. The physical switches have similar protections and it is up to the admin to enable that protection or not.

If you do not enable spoofing of MAC address prior to configuring NLB on the VM you could potentially have problems with the NLB cluster.

When configuring NLB in unicast mode on Hyper-V with enable spoofing of MAC Address disabled you may see some of the following symptoms:

· When initially configuring NLB you will lose network connectivity on the network adaptor NLB was configured on.

· There will be an NLB error event in the Windows Event Log stating that the network adaptor does not support dynamic MAC address updates.

· After rebooting the server, NLB will appear to be bound to the network adapter, but the cluster VIP will not have been added to the network adaptor.

· The cluster MAC address will still be the original MAC address associated with the network adaptor prior to configuring NLB. Use CMD> ipconfig /all to view the MAC address. It should start with "02-BF-***"

· If you ignore all previous symptoms and manually add the VIP you could get an IP conflict if there are other nodes in the cluster that have the same VIP.

With that said, to allow VM guests to run NLB you need to set the VM property for "Enable spoofing of MAC Address".

To enable spoofing of MAC Addresses open the Hyper-V management console. Make sure the VM is stopped open the properties of the VM. Select the Network Adaptor for the NLB VM and check the "Enable spoofing of MAC Address" and click OK. Then start the VM.

Virtual Machine (VM) Failover Policies

2011-06-08T21:04:00.000-07:00

the behavior of the failure policies for a highly available Hyper-V virtual machine running on a Windows Server 2008 R2 Failover Cluster.For the most part, cluster failover policies are generic and apply to all workloads on a cluster, whether it is SQL, a File Server, etc.There is a wealth of documentation out there, but I thought I would take a focused view at understanding what influences where VMs go when a node

Default Failover Policies:

When there is a failure of a node, VMs are spread across the remaining cluster nodes and distributed to the nodes hosting the fewest number of VMs.For example, let’s say that NodeA crashes and it was hosting 10 VMs.The Cluster Service will take one of the VMs, it will then look across the surviving nodes and find the node currently hosting the fewest number of VMs (technically it looks at cluster Group ownership and selects the node with the lowest count).The VM is then started on that node.Then the next VM is selected, then again looks across the cluster again for the node now currently hosting the fewest VMs is selected and the VM is started there.This happens for all VMs until they are all placed.VMs will be distributed across the cluster to different nodes based on who is currently hosting the fewest VMs.

Advanced Failover Policies:

In general the default settings are the right choice for most people, and I recommend you stick with those. However, Clustering does offer a wealth of granular options so you can fine tune the default behavior.

Other Influencers of Failover:

There are a few other settings worth discussing which can influence VM placement and behavior on failover. Let’s discuss some of those:

· Pause Node – At the server level, you can Pause a node. When a node is paused, it means that no VMs (technically no cluster Group) can failover to that node. If a node is paused, it will be removed from the possibility to be a failover target. Pausing a node is handy when doing maintenance tasks like applying a patch, this prevents VMs from failing over to the node when you are doing something to it.

· Disable Failover – For a given VM (technically any cluster Group) you can configure the “Auto Start” setting. If auto start is disabled for a VM, it means that a VM will not be started on failover. This could be useful if you have a low priority VM that you don’t necessarily want to failover, but you still want it to be clustered so that you can, for example, perform live migrations.

Startup Placement Policies

· Persistent Mode – When a cluster as a whole is shut down and then restarted clustering will attempt to start VMs back on the last node they were hosted on. This is controlled by the “Persistent Mode” setting, and is enabled by default. The default amount of time the cluster service will wait for the original node to rejoin the cluster is 30 seconds; this is configurable via the cluster common property ClusterGroupWaitDelay. You may choose to disable Persistent Mode for high priority VMs, where you do not want to wait for the original node to come back… just start the VM as soon as possible.

· Possible Owners – For a given VM (technically any cluster Resource) you can configure the nodes which the VM has the possibility of failing over to. By default it’s all nodes, but if you have a specific node you never want this VM to failover to you can remove it from being a possible owner and prevent it.

· Preferred Owners – For a given VM (technically any cluster Group) you can configure the preference for node order on failover. So let’s say that this VM normally runs on NodeA and you always want it next to go to NodeC if it is available, then preferred owners is a way for you to define a preference of first go to this node, then next go to this other node, then go to this next node. It’s a priority list, and clustering will walk that list in where to place the VM. This will override the default behavior of selecting the node currently hosting the least VMs I described above, and gives you explicit control of where VMs go. More information about Preferred and Possible Owners: http://support.microsoft.com/kb/299631.

· Anti-Affinity – For a given VM (technically any cluster Group) there is a cluster group property called AntiAffinityClassNames that allows you to configure the preference to attempt to keep that VM off the same node as other similar VMs. Let’s say for example you have two domain controllers running in VMs. It would probably be best to keep those running on different nodes if possible. When determining failover, the cluster service will deprioritize any node which is hosting a similar VM. If there is no other option (in the goal of making VMs available) it will place them on the same host. More information: http://msdn.microsoft.com/en-us/library/aa369651(VS.85).aspx.

ESX vs. ESXi

2011-06-08T20:48:00.000-07:00

Capability	VMware ESX	VMware ESXi
Service Console	Service Console is a standard Linux environment through which a user has privileged access to the VMware ESX kernel. This Linux-based privileged access allows you to manage your environment by installing agents and drivers and executing scripts and other Linux-environment code.	VMware ESXi is designed to make the server a computing appliance. Accordingly, VMware ESXi behaves more like firmware than traditional software. To provide hardware-like security and reliability, VMware ESXi does not support a privileged access environment like the Service Console for management of VMware ESXi. To enable interaction with agents, VMware has provisioned CIM Providers through which monitoring and management tasks – traditionally done through Service Console agents – can be performed. VMware has provided remote scripting environments such as vCLI and PowerCLI to allow the remote execution of scripts.
CLI-Based Configuration	VMware ESX Service Console has a host CLI through which VMware ESX can be configured. VMware ESX can also be configured using vSphere CLI (vCLI).	The vSphere CLI (vCLI) is a remote scripting environment that interacts with VMware ESXi hosts to enable host configuration through scripts or specific commands. It replicates nearly all the equivalent COS commands for configuring ESX. Notes: vCLI is limited to read-only access for the free version of VMware ESXi. To enable full functionality of vCLI on a VMware ESXi host, the host must be licensed with vSphere Essentials, vSphere Essential Plus, vSphere Standard, vSphere Advanced, vSphere Enterprise, or vSphere Enterprise Plus. VMware vSphere PowerCLI (for Windows) and vSphere SDK for Perl access ESXi through the same API as vCLI. Similarly, these toolkits are limited to read-only access for the free version of VMware ESXi. When the host is upgraded to vSphere Essentials, vSphere Essential Plus, vSphere Standard, vSphere Advanced, vSphere Enterprise, or vSphere Enterprise Plus these toolkits have write-access and provide a scriptable method for managing ESXi hosts. Certain COS commands have not been implemented in the vCLI because they pertain to the management of the COS itself and not ESXi. For details,
Scriptable Installation	VMware ESX supports scriptable installations through utilities like KickStart.	VMware ESXi Installable does not support scriptable installations in the manner ESX does, at this time. VMware ESXi does provide support for post installation configuration script using vCLI-based configuration scripts.
Boot from SAN	VMware ESX supports boot from SAN. Booting from SAN requires one dedicated LUN per server.	VMware ESXi may be deployed as an embedded hypervisor or installed on a hard disk. In most enterprise settings, VMware ESXi is deployed as an embedded hypervisor directly on the server. This operational model does not require any local storage and no SAN booting is required because the hypervisor image is directly on the server. The installable version of VMware ESXi does not support booting from SAN.
Serial Cable Connectivity	VMware ESX supports interaction through direct-attached serial cable to the VMware ESX host.	VMware ESXi does not support interaction through direct-attached serial cable to the VMware ESXi host at this time.
SNMP	VMware ESX supports SNMP.	VMware ESXi supports SNMP when licensed with vSphere Essentials, vSphere Essential Plus, vSphere Standard, vSphere Advanced, vSphere Enterprise, or vSphere Enterprise Plus. The free version of VMware ESXi does not support SNMP.
Active Directory Integration	VMware ESX supports Active Directory integration through third-party agents installed on the Service Console.	VMware ESXi does not support Active Directory authentication of local users at this time.
HW Instrumentation	Service Console agents provide a range of HW instrumentation on VMware ESX.	VMware ESXi provides HW instrumentation through CIM Providers. Standards-based CIM Providers are distributed with all versions of VMware ESXi. VMware partners include their own proprietary CIM Providers in customized versions of VMware ESXi. These customized versions are available either from VMware’s web site or the partner’s web site, depending on the partner. Remote console applications like Dell DRAC, HP iLO, IBM RSA, and FSC iRMC S2 are supported with ESXi.
Software Patches and Updates	VMware ESX software patches and upgrades behave like traditional Linux based patches and upgrades. The installation of a software patch or upgrade may require multiple system boots as the patch or upgrade may have dependencies on previous patches or upgrades.	VMware ESXi patches and updates behave like firmware patches and updates. Any given patch or update is all-inclusive of previous patches and updates. That is, installing patch version “n” includes all updates included in patch versions n-1, n-2, and so forth. Furthermore, third party components such as OEM CIM providers can be updated independently of the base ESXi component, and vice versa.
VI Web Access	VMware ESX supports managing your virtual machines through VI Web Access. You can use the VI Web Access to connect directly to the ESX host or to the VMware Infrastructure Client.	VMware ESXi does not support web access at this time.
Licensing	For licensing information, see the VMware Sphere Editions Comparison.	For licensing information, see the VMware Sphere Editions Comparison.
Diagnostics and Troubleshooting	VMware ESX Service Console can be used to issue commands that can help diagnose and repair support issues with the server.	VMware ESXi has several ways to enable support of the product: Remote command sets such as the vCLI include diagnostic commands such as vmkfstools, resxtop, and vmware-cmd. The console interface of VMware ESXi (known as the DCUI or Direct Console User Interface) has functionality to help repair the system, including restarting of all management agents. Tech Support Mode, which allows low-level access to the system so that advanced diagnostic commands can be issues. For more information,
Jumbo Frames	VMware ESX 4.0 fully supports Jumbo Frames.	VMware ESXi 4.0 fully supports Jumbo Frames.

Active Directory Federation Services (ADFS)

2011-06-08T06:43:00.000-07:00

Federation Services were originally introduced in Windows Server 2003 R2. F provides an identity access solution, and AD Federation Services provides authenticated access to users inside (and outside) an organization to publicly (via the Internet) accessible applications. Federation Services provides an identity management solution that interoperates with WS-* Web Services Architecture–enabled security products. WS-Federation Passive Requestor Profile (WS-F PRP) also makes it possible for federation to work with solutions that do not use the Microsoft standard of identity management. The WS-Federation specification defines an integrated model for federating identity, authentication, and authorization across different trust realms and protocols. This specification defines how the WS-Federation model is applied to passive requestors such as Web browsers that support the HTTP protocol. WS-Federation Passive Requestor Profile was created in conjunction with some pretty large companies, including IBM, BEA Systems, Microsoft, VeriSign, and RSA Security.

What Is Federation?

As we described earlier in this chapter, federation is a technology solution that makes it possible for two entities to collaborate in a variety of ways. When servers are deployed in multiple organizations for federation, it is possible for corporations to share resources and account management in a trusted manner. Earlier in this chapter, we were discussing Active Directory Rights Management Server. This is just one way companies can take advantage of FS. With ADFS, partners can include external third parties, other departments, or subsidiaries in the same organization.

Why and When to Use Federation

Federation can be used in multiple ways. One product that has been using federation for quite some time is Microsoft Communication Server (previously, Live Communication Server 2005, now rebranded as Office Communication Server 2007). Federation is slightly different in this model, where two companies can federate their environments for the purposes of sharing presence information. This makes it possible for two companies to securely communicate via IM, Live Meeting, Voice, and Video. It also makes it possible to add “presence awareness” to many applications, including the Office suite, as well as Office SharePoint Server. If you want to know more about OCS and how federation works for presence, we recommend How to Cheat at Administering Office Communication Server 2007, also by Elsevier.

A little closer to home, Federation Services can also be used in a variety of ways. Let’s take an extranet solution where a company in the financial service business shares information with its partners. The company hosts a Windows SharePoint Services (WSS) site in their DMZ for the purposes of sharing revenue information with investment companies that sell their products. Prior to Active Directory Federation Services, these partners would be required to use a customer ID and password in order to access this data. For years, technology companies have been touting the ability to provide and use single sign-on (SSO) solutions. These worked great inside an organization, where you may have several different systems (Active Directory, IBM Tivoli, and Solaris), but tend to fail once you get outside the enterprise walls.

With AD FS, this company can federate their DMZ domain (or, their internal AD) with their partner Active Directory infrastructures. Now, rather than creating a username and password for employees at these partners, they can simply add the users (or groups) to the appropriate security groups in their own Active Directory (see Figure 1). It is also important to note that AD FS requires either Windows Server 2008 Enterprise edition or Datacenter edition.

Figure 1. The Active Directory Federation Services Structure

Configuring ADFS

In this exercise, we are going to create the account side of the ADFS structure. The resource is the other half of the ADFS configuration, which is the provider of the service that will be provided to an account domain. To put it in real-world terms, the resource would provide the extranet application to the partner company (the account domain).

Configuring Federation Services

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

1.	Click Start \| Administrative Tools \| Server Manager.
2.	Scroll down to Role Summary, and then click Add Roles.
3.	When the Before You Begin page opens, click Next.
4.	On the Select Server Roles page, select Active Directory Federation Services (see Figure 2) from the list and click Next. Figure 2. Selecting the Role
5.	Click Next on the Active Directory Federation Services page.
6.	In the Select Role Services window, select Federation Service, and then click Next. If prompted, add the additional prerequisite applications.
7.	Click Create A Self-Signed Certificate For SSL Encryption (Figure 3), and then click Next. Figure 3. Creating a Self-Signed Token-Signing Certificate
8.	Click Create A Self-Signed Token-Signing Certificate, and then click Next.
9.	Click Next on the Select Trust Policy page.
10.	If prompted, click Next on the Web Server (IIS) page.
11.	If prompted, click Next on the Select Role Services page.
12.	On the Confirm Installation Selections page, click Install.
13.	When the installation is complete, click Close.

The next step in configuring AD FS is to configure IIS to require SSL certificates on the Federation server:

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

1.	Choose Start \| Administrative Tools \| Internet Information Services (IIS) Manager.
2.	Double-click the server name.
3.	Drill down the left pane to the Default Web Site and double-click it.
4.	Double-click SSL Settings and select Require SSL.
5.	Go to Client Certificates and click Accept. Then, click Apply (Figure 4). Figure 4. Requiring Client Certificates
6.	Click Application Pools.
7.	Right-click AD FS AppPool, and click Set Application Pool Defaults.
8.	In the Identity pane (Figure 5), click LocalSystem, and then click OK. Figure 5. Setting Application Pool Defaults
9.	Click OK again.
10.	Before we close IIS, we need to create a self-signed certificate. Double-click the server name again.
11.	Double-click Server Certificates.
12.	Click Create Self-Signed Certificate.
13.	In the Specify Friendly Name field, enter the NetBIOS name of the server and click OK.

Next, we need to configure a resource for use with AD FS. In this case, we are going to use the same domain controller to double as a Web server. What we will be doing is installing the AD FS Web Agent, essentially adding an additional role to the server, as part of the AD FS architecture. This will allow us to use our federated services within a Web application.

<><><>

1.	Choose Start \| Administrative Tools \| Server Manager. Scroll down to Role Summary, and then click Add Roles.
2.	When the Before You Begin page opens, click Active Directory Federation Services.
3.	Scroll down to Role Services and click Add Role Services.
4.	In the Select Role Services window, select Claims-aware Agent (Figure 6), and then click Next. Figure 6. Setting Services
5.	Confirm the installation selections (Figure 7), and then click Install. Figure 7. Confirming the Installation
6.	When installation is complete, click Close.

Now we need to configure the trust policy which would be responsible for federation with the resource domain.

1.	Choose Start \| Administrative Tools \| Active Directory Federation Services.
2.	Expand Federation Service by clicking the + symbol (see Figure 8). Figure 8. AD FS MMC
3.	Right-click Trust Policy, and then choose Properties.
4.	Verify the information in Figure 9 matches your configuration (with the exception of the FQDN server name), and then click OK. Figure 9. Trust Policies
5.	When you return to the AD FS MMC, expand Trust Policy and open My Organization.
6.	Right-click Organization Claims, and then click New \| Organization Claim.
7.	This is where you enter the information about the resource domain. A claim is a statement made by both partners and is used for authentication within applications. We will be using a Group Claim, which indicates membership in a group or role. Groups would generally follow business groups, such as accounting and IT.
8.	Enter a claim name (we will use PrepGuide Claim). Verify that Group Claim is checked as well before clicking OK.
9.	Create a new account store. Account stores are used by AD FS to log on users and extract claims for those users. AD FS supports two types of account stores: Active Directory Domain Services (AD DS) and Active Directory Lightweight Directory Services (AD LDS). This makes it possible to provide AD FS for full Active Directory Domains and AD LDS domains.
10.	Right-click Account Store and choose New \| Account Store.
11.	When the Welcome window opens, click Next.
12.	Since we have a full AD DS in place, select Active Directory Domain Services (AD DS) from the Account Store Type window (Figure 10), and then click Next. Figure 10. The Account Store Type Window
13.	Click Next on the Enable This Account Store window.
14.	Click Finish on the completion page.

Now, we need to add Active Directory groups into the Account Store.

1.	Expand Account Stores.
2.	Right-click Active Directory, and then click New \| Group Claim Extraction.
3.	In the Create A New Group Claim Extraction window (Figure 11), click Add and click Advanced. Figure 11. The Create A New Group Claim Extraction Window
4.	Click Object Types, remove the checkmarks from everything except Groups, and then click OK.
5.	Click Find Now.
6.	Select Domain Admins from the list of groups by double-clicking.
7.	Click OK.
8.	The Map To This Organization Claim field should show the claim we created earlier. Click OK to close the window.

Finally, we will work to create the partner information of our resource partner, which is prepguides.ads.

1.	Expand Partner Organizations.
2.	Right-click Resource Partners, and then select New \| Resource Partner.
3.	Click Next on the Welcome window.
4.	We will not be importing a policy file, so click Next.
5.	In the Resource Partner Details window (Figure 12), enter a friendly name for the partner, and the URI and URL information of the partner. Note it is identical to what we entered earlier in Figure 9. When the information is complete, click Next. Figure 12. Resource Partner Details
6.	Click Next on the Federation Scenario page. This is the default selection, which is used for two partners from different organizations when there’s no forest trust.
7.	On the Resource Partner Identity Claims page, check UPN Claim and click Next. A UPN Claim is based on the domain name of your Active Directory structure. In our case, the UPN is uccentral.ads.
8.	Set the UPN suffix. Verify that Replace All UPN Suffixes With The Following: is selected and then enter your server’s domain name. This is how all suffixes will be sent to the resource partner. Click Next.
9.	Click Next to enable the partner.
10.	Click Finish to close the wizard.

We’re almost at the end of our account partner configuration. The last thing we need to do is create an outgoing claim mapping. This is part of a claim set. On the resource side, we would create an identical incoming claim mapping.

1.	Expand Resource Partners.
2.	Right-click your resource partner, and then choose New \| Outgoing Group Claim Mapping.
3.	Select the claim we created earlier, enter PrepGuide Mapping, and then click OK.

Using ActiveDirectory Federation Services for single sign-on

2011-06-08T06:29:00.000-07:00

Web-based log-in and SharePoint-based sites create a need for a new system of trust, and ADFS could be the solution

You have developed a Web site that requires a log-in. However, rather than promoting your site to individuals who sign up and create their personal log-in, you promote the site to entire companies. A company with thousands of employees signs up to use your site and you are suddenly faced with the need to re-create thousands of accounts on your server. Users, when accessing the site, must perform the most frustrating task: logging in with a different account. You sit back and think, "There must be a better way."

Well, that is only one of many scenarios where people in one company need to access items in another company or have a single sign-on for another site, be it a SharePoint site or some other type that requires a log-in. Here is where it may be worth looking into ADFS (Active Directory Federation Services).

How ADFS works

Essentially, with ADFS, each company manages its own identities. But within a federated environment, each company can accept and provide permissions and/or access to identities from within another company. It all comes down to trust. The ability to trust accounts from one company without requiring a local account on your servers. This trust is called federated identity management and is the core behind ADFS. The biggest concern, logically, is security. All communication from one company's Active Directory to the other's ADFS is encrypted, and client access to through their browser is also encrypted using SSL.

It's important to mention that ADFS is only for Web-based applications (like SharePoint). It's really a solution only for allowing external business partners or clients to access your Web application, while still allowing the partner or client to manage their identities.

There are a few scenarios where you might use ADFS. One is the single sign-on where a person does have to log in one time through forms-based authentication, which will provide the users with a cookie that they can then use to access the rest of the site without having to provide repeat credentials. Another option is the identity federation option where they use their token from Active Directory to access the Web application without having to reauthenticate at all.

Troubleshooting Certificate Autoenrollment in Active Directory Certificate Services (AD CS)

2011-06-08T06:24:00.000-07:00

These are the steps to troubleshoot autoenrollment problems. The basis for this article was produced by a veteran field troubleshooting engineer, Roger Grimes. The article assumes that certificates that a user or machine should be receiving automatically from an issuing CA server on the network are not showing up in the end-users’s certificate store (i.e. Personal store in the Certificates console (certmgr.msc)).
First Make Sure:

Issuing CA’s computer account is in Cert Publishers group for the domain (can verify using Active Directory Users and Computers)
Effective GPOs have Autoenrollment turned on
User or computer has Read, Enroll, and Autoenroll permissions on the certificate template being requested
- You can run certutil.exe –Template when logged in as the end-user to see if the end-user has Read and Enroll permissions (but it will not reveal which certs the user has Autoenroll permissions to)
Make sure certificate request isn’t pending or failed status in Certification Authority console.

Verify that Autoenrollment is turned on:

View appropriate effective GPOs (using Active Directory Users and Computers or the Group Policy Management console)
On the user’s computer, run rsop.msc and check both user and computer configuration objects,
Rsop results will only show what was pushed by GPOs, not what actually was applied.
To see that autoenrollment is actually turned on the computer, check the following registry keys for a DWord value of 7 in AEPolicy:
- HKCU\Software\Policies\Microsoft\Cryptography\AutoEnrollment (for user certs)

HKLM\Software\Policies\Microsoft\Cryptography\AutoEnrollment (for PC certs)

If no values are there, check the non-GPO locations (but it means AD GPOs are not working):

HKLM\Software\Microsoft\Cryptography\AutoEnrollment
HKCU\Software\ Microsoft\Cryptography\AutoEnrollment

If none of these keys have AEPolicy = 7, Autoenrollment is not turned on.

Forcing Autoenrollment and Viewing Results If previous steps above are set correctly, force Autoenrollment and look into Application log to see what happens when Autoenrollment takes place.
First, set new registry key to turn on more detailed autoenrollment auditing:

In HKCU\Software\Microsoft\Cryptography\Autoenrollment and HKLM\Software\Microsoft\Cryptography\Autoenrollment, create a new DWORD value named AEEventLogLevel and set its value to 0.

Open up Application Log in Event Viewer (eventvwr.exe).
Force Autoenrollment:
gpupdate /force
In the Application event log, refresh the log to see what happens during autoenrollment.
Two computer autoenrollment messages (start, stop) should occur first, followed by two user autoenrollment messages (start, stop) in 30 sec. – 2 minutes. Any issued certs should appear in the log as Event ID 18’s or 19’s. Stop and Start messages are event IDs 2 and 3.
If there are any valid autoenrollment certificates to be issued, they should issue here.
Note: If the CA administrator configured the templates to not duplicate certificates if one already exists in Active Directory, you will have to delete the user’s certificate in Active Directory in order for Autoenrollment to pull down a new certificate.
To Troubleshoot GPO Errors
If you do see any GPO errors, you can turn on Group Policy logging on the client. Trigger Group Policy manually (gpupdate /force). Then check the policy log.
For XP:

- Set the following registry flag:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Flag - DWORD: UserEnvDebugLevel
Value: 0x00030002

- Rename the current GPO log file, userenv.log, to userenv.old

- Run the following in a CMD prompt as the user: gpupdate /force

- Check the following log file for any errors: %windir%\debug\usermode\userenv.log

Active Directory Lightweight Directory Services (AD LDS) Overview

2011-06-08T06:19:00.000-07:00

Windows Server® 2008 Active Directory® Lightweight Directory Services (AD LDS) role, formerly known as Active Directory Application Mode (ADAM), you can provide directory services for directory-enabled applications without incurring the overhead of domains and forests and the requirements of a single schema throughout a forest.

In the following sections, learn more about the AD LDS server role, the features in it, and the software and hardware considerations for installing it.

What is the AD LDS server role?

AD LDS is a Lightweight Directory Access Protocol (LDAP) directory service that provides flexible support for directory-enabled applications, without the dependencies that are required for Active Directory Domain Services (AD DS). AD LDS provides much of the same functionality as AD DS, but it does not require the deployment of domains or domain controllers. You can run multiple instances of AD LDS concurrently on a single computer, with an independently managed schema for each AD LDS instance.

AD DS provides directory services for both the Microsoft® Windows Server server operating system and for directory-enabled applications. For the server operating system, AD DS stores critical information about the network infrastructure, users and groups, network services, and so on. In this role, AD DS must adhere to a single schema throughout an entire forest.

The AD LDS server role, on the other hand, provides directory services specifically for directory-enabled applications. AD LDS does not require or rely on Active Directory domains or forests. However, in environments where AD DS exists, AD LDS can use AD DS for the authentication of Windows security principals.

When should I use the AD LDS server role?

The following sections describe common AD LDS enterprise directory solutions.

Providing an enterprise directory store

AD LDS is a full-fledged LDAP directory solution for enterprises. All directory-enabled enterprise applications can use AD LDS as their directory store.

AD LDS can store “private” directory data, which is relevant only to the application, in a local directory service—possibly on the same server as the application—without requiring any additional configuration to the server operating system directory. This data, which is relevant only to the application and which does not have to be widely replicated, is stored solely in the AD LDS directory that is associated with the application. This solution reduces replication traffic on the network between domain controllers that serve the server operating system directory. However, if necessary you can configure this data to be replicated between multiple AD LDS instances.

Enterprise applications must often store personalization data that is associated with authenticated users in AD DS. Storing this personalization data in AD DS would require AD DS schema changes. In this scenario, an application can use AD LDS to store application-specific data, such as policy and management information, while it uses the user principals in AD DS for authentication and for controlling access to objects in AD LDS. Such a solution makes it unnecessary for each AD LDS directory to have its own user database. Therefore, this solution prevents a proliferation of user IDs and passwords for end users every time a new directory-enabled application is introduced to the network.

Providing an extranet authentication store

Consider the example of a Web portal application that manages extranet access to corporate business applications and services identities that are external to the corporate AD DS. Another example might be a hosting scenario in which a provider offers domain and storage services to its customers by maintaining and updating customer-dedicated Web or data servers, with no customers having access to these servers.

These servers and portal applications that are deployed in an extranet have custom identity needs. They require an authentication store to save authorization information for the identities that they service. AD LDS is a good candidate for this authentication store because it can host user objects that are not Windows security principals but that can be authenticated with LDAP simple binds. In other words, Web clients can be serviced by portal applications that can run on any platform while they use AD LDS as a simple LDAP authentication store.

If a portal application that you deploy in an extranet must service internal AD DS-authenticated identities that are currently located outside the corporate firewall, you can still deploy AD LDS as the authentication store with the corporate account credentials of these identities provisioned on the extranet instances of AD LDS, as shown in the following illustration.

You can also deploy AD LDS as an extranet authentication store along with Active Directory Federation Services (AD FS). This configuration enables Web single-sign-on (SSO) technologies to authenticate users to multiple Web applications with a single user account. For more information, see Active Directory Federation Services Overview (http://go.microsoft.com/fwlink/?LinkId=95311).

Consolidating identity systems

You may have a scenario in which a data model restriction, such as a single LDAP partition view or a single organizational unit (OU) view, is imposed on an enterprise directory-enabled application that must access data that is associated with AD DS-authenticated users, applications, or network resources that are located in multiple forests, domains, or OUs in the enterprise. Identity information for this directory-enabled application must be consolidated from multiple Active Directory forests, domains, and OUs or from multiple identity systems and other directories, such as human resource databases, SAP databases, telephone directories, and so on.

AD LDS offers a consolidating directory solution because you can deploy it along with a metadirectory. Metadirectories, such as Microsoft Identity Integration Server (MIIS) or Microsoft Identity Integration Feature Pack (IIFP)—which is a free, lightweight version of MIIS, can provide directory-enabled applications with a unified view of all known identity information about enterprise users, applications, and network resources by performing identity integration, directory synchronization, account provisioning and deprovisioning, and password synchronization between AD DS and AD LDS, as shown in the following illustration.

Providing a development environment for AD DS and AD LDS

Because AD LDS uses the same programming model and provides virtually the same administration experience as AD DS, it can be a good fit for developers who are staging and testing various Active Directory-integrated applications. For example, if an application under development requires a different schema from the current server operating system AD DS, the application developer can use AD LDS to provide the application with a tailored schema that works for business needs, data requirements, and workflow processes, without altering the configuration of the corporate Active Directory deployment. Developers can work with an AD LDS instance without the need for a complicated setup and later move the application to AD DS. Developers may want a directory that they can easily program to without requirements for extensive setup or hardware support during the development process. This can be achieved through AD LDS as it can easily be installed and uninstalled on any Windows Server 2008 computer. This allows rapid restoration to a clean state during the application prototyping and development process.

Providing a configuration store for distributed applications in Windows Server

You may have a distributed application that requires a configuration store with multimaster update and replication capabilities to service its multiple components, for example, a firewall application that accesses network and application ports data, a junk mail filtering application that accesses e-mail address lists, or a workflow application that accesses enterprise and policy data. You can deploy AD LDS as a lightweight configuration store for such applications, as shown in the following illustration.

In this scenario, an AD LDS instance that serves as the application's configuration store is bundled with a distributed application. This way, application designers do not have to be concerned about the availability of a directory service before the installation of the application. Instead, they can include AD LDS as a part of their application’s installation process to ensure that the application has access to a directory service immediately upon installation. The application then configures and manages AD LDS entirely on its own or partially, depending on the application’s exposure to the AD LDS management, and it uses AD LDS to address its various data requirements.

Migrating legacy directory-enabled applications

Your organization may use an already established directory with X.500-style naming (O=<organization>,C=<country>) to serve various legacy applications, but it may also want to migrate its enterprise directory to AD DS. In this scenario, you can use AD LDS as an interim solution. You can deploy AD LDS to serve and provide support for the legacy applications that rely on X.500-style naming, while you can use AD DS in the enterprise to provide a shared security infrastructure. You can use a metadirectory, such as MIIS, to automatically synchronize the data in AD DS and AD LDS for a seamless migration experience. The following illustration describes this AD LDS deployment.

Features in the AD LDS server role

You can use the AD LDS server role to create multiple AD LDS instances on a single computer. Each instance runs as a separate service in its own execution context. The AD LDS server role includes the following features to make it easy to create, configure, and manage AD LDS instances:

A wizard that guides you through the process of creating an AD LDS instance
Command-line tools for performing unattended installation and removal of AD LDS instances
Microsoft Management Console (MMC) snap-ins for configuring and managing AD LDS instances, including the schema for each instance
AD LDS-specific command-line tools for managing, populating, and synchronizing AD LDS instances

In addition to these tools, you can also use many Active Directory tools to administer AD LDS instances.

The Windows Server 2008 operating system includes the additional AD LDS features in the following table.

Feature	Description
Install from Media (IFM) Generation	With this feature, you can use a one-step Ntdsutil.exe or Dsdbutil.exe process to create installation media for subsequent AD LDS installations.
Audit AD LDS changes	With this feature, you can set up AD LDS auditing with a new audit subcategory to log old and new values when changes are made to objects and their attributes. Note: This feature also applies to AD DS. For more information, see AD DS: Auditing (http://go.microsoft.com/fwlink/?LinkId=94846).
Data Mounting Tool	With this feature, you can view directory data that is stored online in snapshots that are taken at different points in time to better decide which data to restore, without having to restart the server. Note: This feature also applies to AD DS. For more information, see AD DS: Data Mounting Tool (http://go.microsoft.com/fwlink/?LinkId=94847).
Support for Active Directory Sites and Services	With this feature, you can use the Active Directory Sites and Services snap-in to manage replication among AD LDS instances. To use this tool, you must import the classes in MS-ADLDS-DisplaySpecifiers.LDF to extend the schema of a configuration set that you want to manage. To connect to an AD LDS instance that hosts your configuration set, specify the computer name and the port number of a server that hosts this AD LDS instance.
Dynamic list of LDAP Data Interchange Format (LDIF) files during instance setup	With this feature, you can make custom LDIF files available during AD LDS instance setup—in addition to the default LDIF files that are provided with AD LDS—by adding the files to the %systemroot%\ADAM directory.
Recursive linked-attribute queries	With this feature, you can create a single LDAP query that can follow nested attribute links. This can be very useful in determining group membership and ancestry. For more information, see article 914828 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=94828).

Installing Windows 98 on Windows Virtual PC

2011-06-07T06:54:00.000-07:00

Windows Virtual PC only officially supports Windows XP, Windows Vista and Windows 7 as guest operating systems. Thankfully it has great compatibility and can run many operating systems that are not officially supported.
I recently needed to setup a Windows 98 virtual machine for my wife – who has some genealogy software that will not even run on Windows XP. To do this I created a new virtual machine and configured it with 64mb of RAM and a 16GB virtual hard disk.
I was then able to install Windows 98 with no real problems:

Some things to be aware of when doing this:

I originally created the virtual machine with 128mb of RAM – but that caused problems for the setup program. Setting the memory to 64mb allowed the installation to go through successfully – and I was able to increase the memory after the operating system installation.
I happen to have a bootable Windows 98 installation CD – but most Windows 98 installation CDs are not bootable. If you have one of these – you need to use a boot floppy – which means you will need these scripts for attaching floppy disks to virtual machines.
While I used a 16GB virtual hard disk – because that is all that I needed – I have tried this with disks up to 127GB in size and not seen any problems.

After installation both networking and sound work correctly – but the video is kind of “sucky” and you need to capture / release the mouse whenever you use the virtual machine. Luckily you can address both of these issues by installing older virtual machine additions in the virtual machine. Doing this will give you:

Better graphics
Integrated mouse functionality
Desktop resizing

But you will not get:

Clipboard integration
Time synchronization
Shared Folders
Printer / smart card sharing

But how do you do this? The trick is to extract the old virtual machine additions out of a previous product. In my case I decided to get the virtual machine additions out of Virtual Server 2005 R2. To do this what you will need to do is:

Download Virtual Server 2005 R2 SP1
Download the Virtual Server 2005 R2 SP1 Update
Put both files in a temporary working directory (I used C:\work)
Rename the Virtual Server setup.exe to 1setup1.exe
- This is needed to get around the Windows application compatibility check, which we do not care about as we will not be installing Virtual Server
Open a command prompt and change to your temporary working directory
Run:
1setup1.exe /c /t . This will extract the installation files out of the executable file
Next run:
start /wait msiexec /a "Virtual Server 2005 Install.msi" TARGETDIR="C:\Work\bits" /qn
This will extract all of the files out of the setup package
Finally run:
start /wait msiexec /p KB948515.msp /a "C:\Work\bits\Virtual Server 2005 Install.msi" /qn This will apply the Virtual Server 2005 R2 SP1 update to the extracted files
Make a copy of the virtual machine additions ISO – which will be at C:\Work\Bits\Program Files\Microsoft Virtual Server\Virtual Machine Additions\VMAdditions.iso
You can delete all the other files now – as that ISO file is the only one you need

At this stage you should start up your Windows 98 virtual machine and login. Then attach the VMAdditions.iso file to the virtual machine. The virtual machine additions installer should start automatically inside the virtual machine:

After this you will need to reboot the virtual machine.
With all this in place – some parting notes that I have are:

Do not connect this to a network! Seriously. Windows 98 is no longer supported by Microsoft – and security updates are not being released. Furthermore – there are no antivirus programs that are being actively maintained for Windows 98. So it is just a terrible idea to do.
If you do have to connect it to the network – here are some tips:
- Configure the virtual machine to use Shared Networking (NAT) – that will at least protect it from active network based attacks
- You can install Internet Explorer 6 from here – but please, please, please do not use the virtual machine for general purpose web browsing
- The Windows Update link in Windows 98 is broken – but you can use Windows Update by manually going to http://windowsupdate.microsoft.com/

Using Floppy Disks with Windows Virtual PC

2011-06-07T06:51:00.000-07:00

Windows Virtual PC does support the use of floppy disks – but as this feature is only used by a small subset of users – we did not expose this in the user interface. To use floppy disks you need to have a script to help you. And here are the scripts:

VBScript:

Option Explicit ' Define constants for floppy drive attachment typesCONST vmFloppyDrive_None = 0CONST vmFloppyDrive_Image = 1CONST vmFloppyDrive_HostDrive = 2 Dim namedArguments, argumentError, vpc, vm, vmName, action, floppy, vmFloppyDrive ' Check that the script is running at the command line.If UCase(Right(Wscript.FullName, 11)) = "WSCRIPT.EXE" ThenWScript.Echo "This script must be run under CScript."WScript.QuitEnd If ' Get the virtual machine name / floppy commands from the command-line argumentsSet namedArguments = WScript.Arguments.Named argumentError = false If namedArguments.Exists("vm") ThenvmName = namedArguments.Item("vm")ElseargumentError = trueEnd If If namedArguments.Exists("action") Thenaction = namedArguments.Item("action")ElseargumentError = trueEnd If If namedArguments.Exists("floppy") Thenfloppy = namedArguments.Item("floppy")ElseIf (not ((action = "info") or (action = "disconnect"))) ThenargumentError = trueEnd IfEnd If ' Display usage information if wrong arguments are providedif argumentError thenWScript.Echo "Missing command-line argument"WScript.EchoWScript.Echo "Usage: FloppyDrive.vbs /vm:" & chr(34) & "Name of virtual machine to be started" & chr(34)WScript.EchoWScript.Echo "                       /action:info       - to display information about the current floppy configuration"WScript.Echo "                               disconnect - to disconnect any attached floppy disk or floppy disk image"WScript.Echo "                               vfd        - to attach a virtual floppy disk image"WScript.Echo "                               physical   - to attach a physical floppy disk"WScript.EchoWScript.Echo "                       /floppy:name       - where name is either the full name and path for a virtual"WScript.Echo "                                            floppy disk or the letter of a physical disk to attach"WScript.EchoWScript.Quitend if ' Attempt to connect to Virtual PCOn Error Resume NextSet vpc = CreateObject("VirtualPC.Application")If Err.Number <> 0 ThenWScript.Echo "Unable to connect to Virtual PC."WScript.QuitEnd ifOn Error Goto 0 ' Get virtual machine objectSet vm = vpc.FindVirtualMachine(vmName) ' Get the floppy driveset vmFloppyDrive = vm.FloppyDrives.item(1) ' Perform the specified actionSelect Case action ' Display floppy disk informationcase "info"wscript.echo "Floppy disk information"wscript.echo "=======================" ' Different information is needed for each attachment typeselect case vmFloppyDrive.Attachmentcase vmFloppyDrive_None wscript.echo "Floppy Attachment : No floppy disk attached"wscript.echo "Drive Number      : " & vmFloppyDrive.DriveNumbercase vmFloppyDrive_Image wscript.echo "Floppy Attachment : Floppy disk image attached"wscript.echo "Drive Number      : " & vmFloppyDrive.DriveNumberwscript.echo "Image File        : " & vmFloppyDrive.ImageFile case vmFloppyDrive_HostDrive wscript.echo "Floppy Attachment : Physical floppy disk attached"wscript.echo "Drive Number      : " & vmFloppyDrive.DriveNumberwscript.echo "Host Drive Letter : " & vmFloppyDrive.HostDriveLetter end select ' Disconnect the current floppy diskcase "disconnect" wscript.echo "Disconnecting the floppy disk." ' A different method is used to disconnect a floppy disk image than for a physical disk select case vmFloppyDrive.Attachmentcase vmFloppyDrive_Image vmFloppyDrive.ReleaseImagecase vmFloppyDrive_HostDrive vmFloppyDrive.ReleaseHostDriveend select ' Attach a floppy disk imagecase "vfd" wscript.echo "Attaching " & floppy & " to the floppy drive."vmFloppyDrive.AttachImage(floppy) ' Attach a physical floppy diskcase "physical" wscript.echo "Attaching physical disk " & floppy & ": to the floppy drive."vmFloppyDrive.AttachHostDrive(floppy) ' Catch invalid actionscase elsewscript.echo "Invalid action provided. Info, disconnect, vfd and physical are valid options." end select wscript.echo

PowerShell:

param([string]$vmName, [string]$action, [string]$floppy) $argumentError = 0 # Check for correct command-line argumentsIf ($vmName -eq ""){$argumentError = 1} If ($action -eq ""){$argumentError = 1} If ($floppy -eq ""){if ((!([string]::Compare($action, "vfd", $True))) -or (!([string]::Compare($action, "physical", $True)))){$argumentError = 1}} # Display usage information if wrong arguments are providedIf ($argumentError -eq 1){write-host "Missing command-line argument."write-host "USage: FloppyDrive.ps1 -vmName `"Name of virtual machine`""write-host "                       -action info       - to display information about the current floppy configuration"write-host "                               disconnect - to disconnect any attached floppy disk or floppy disk image"write-host "                               vfd        - to attach a virtual floppy disk image"write-host "                               physical   - to attach a physical floppy disk"write-hostwrite-host "                       -floppy name       - where name is either the full name and path for a virtual"write-host "                                            floppy disk or the letter of a physical disk to attach"exit} # Connect to Virtual PC$vpc=new-object –com VirtualPC.Application –Strict # Get virtual machine object$vm = $vpc.FindVirtualMachine($vmName) # Get the floppy drive$vmFloppyDrive = $vm.FloppyDrives.item(1) # Perform the specified actionswitch ($action) { # Display floppy disk information"info" {write-host "Floppy disk information"write-host "=======================" # Different information is needed for each attachment typeswitch ($vmFloppyDrive.Attachment){0 {write-host "Floppy Attachment : No floppy disk attached"write-host "Drive Number      : " $vmFloppyDrive.DriveNumber}1 { write-host "Floppy Attachment : Floppy disk image attached"write-host "Drive Number      : " $vmFloppyDrive.DriveNumberwrite-host "Image File        : " $vmFloppyDrive.ImageFile }2 { write-host "Floppy Attachment : Physical floppy disk attached"write-host "Drive Number      : " $vmFloppyDrive.DriveNumberwrite-host "Host Drive Letter : " $vmFloppyDrive.HostDriveLetter }}} # Disconnect the current floppy disk"disconnect" { write-host "Disconnecting the floppy disk." # A different method is used to disconnect a floppy disk image than for a physical disk switch ($vmFloppyDrive.Attachment){1 {$vmFloppyDrive.ReleaseImage()}2 {$vmFloppyDrive.ReleaseHostDrive()}}} # Attach a floppy disk image"vfd" {write-host "Attaching " $floppy " to the floppy drive."$vmFloppyDrive.AttachImage($floppy)}# Attach a physical floppy disk"physical"  {write-host "Attaching physical disk " $floppy ": to the floppy drive."$vmFloppyDrive.AttachHostDrive($floppy)}# Catch invalid actionsdefault {write-host "Invalid action provided. Info, disconnect, vfd and physical are valid options."}}

Installing Ubuntu Server 10.10 on Hyper-V

2011-06-07T06:38:00.000-07:00

After downloading the bits from http://www.blogger.com/goog_2019813541 I created a quad-processor virtual machine with a non-legacy network adapter.
Installation was fairly straight forward:

However – Ubuntu does not have the Hyper-V enlightened network drivers enabled by default – so the installation complains about not being able to find any network adapters:

But I just ignored that and moved along with the install:

I chose the default packages for setting up a LAMP server:

The install finished and I was dropped at the login prompt:

A cool thing to note was that at this stage I could already shut down the virtual machine by using the shutdown button on the Virtual Machine Connection window, so part of the integration services are already running. You can also see that all four virtual processors are there and working:

Getting the Hyper-V drivers up and running at this point in time is actually relatively simple. The first thing you need to do is to edit /etc/initramfs-tools/modules and add the following lines to the end of it:
hv_vmbus
hv_storvsc
hv_blkvsc
hv_netvsc
Once you have made these changes you will need to run “update-initramfs –u” and reboot. You will now have the Hyper-V drivers for storage and networking loaded:

You can confirm that these drivers are loaded by running “lsmod” after the reboot:

The final thing you need to do is to configure networking (because that step was skipped during installation). The first thing to do is to run “ifconfig –a” to find out what name your network adapter has been given. In my case it was “eth0” – but this is not always the name it will get. Once you know the name you will need to edit /etc/network/interfaces and add the following to the end of the file:
For DHCP (what I did):
Auto eth0
iface eth0 inet dhcp
For a Static IP address:
Auto eth0
iface eth0 inet static
address [insert your IP address]
netmask [insert your netmask]
Gateway [insert your gateway address]

Like this:

One more reboot and running “ifconfig” should confirm that everything is working:

And in my case I could also confirm that the website was accessible from my parent partition as well:

Ubuntu Server 10.10 running under Hyper-V with full integration services using nothing other than what is included on the Ubuntu install media.

Active Directory Replication

2011-06-06T19:49:00.000-07:00

Active Directory Replication

The initial versions of Windows NT were designed as single master network environments. The primary domain controller (PDC) was responsible for managing the master copy of the domain database. The PDC was therefore responsible for replicating any changes to the backup domain controllers (BDCs). In these environments, any changes had to be performed on the PDC who then replicated these database changes to the BDCs. What this meant was that in cases where the PDC was unavailable, no changes were made to the domain database. From this simple discussion, it is clear that the single master environment of the earlier versions of Windows NT had a limitation when it came to reliability and continuously ensuring that changes could be made to the domain database.
In the majority of network environments, more than one domain controller has to exist to provide fault tolerance, and improve reliability and performance. Fault tolerance is present when business continuity exists when one domain controller fails because the other domain controller(s) in the environment are able to supply network resources. Having multiple domain controllers in your network environment improves performance because the processing load can be distributed to all domain controllers.
Active Directory differs from the design of the earlier Windows NT domain environments because it is designed to be a scalable, distributed multimaster replicated database. Information on network resources within the organization is stored within the Active Directory database. In addition to this, all domain controllers host a full replica of the domain information for its own domain. Domain controllers in Windows 2000 and Windows Server 2003 environments hold a read/write copy of the Active Directory database. Domain controllers in these environments therefore maintain and manage the replica of all Active Directory objects (network resources) located in the domain to which it is a member of.
In Windows 2000 and Windows Server 2003 environments, in Active Directory terminology, each domain controller contains a full copy of its own directory partition. Another term used to refer to directory partition is naming context. In Active Directory environments, a directory tree contains all Active Directory objects in the forest. A forest is the grouping of two or more domain trees or domains that do not have a common contiguous namespace, that is, they have non-contiguous namespaces. In Active Directory, the directory tree is partitioned. This enables portions of the tree to be distributed to domain controllers in other domains in the forest. Back to Active Directory terminology, the copy of the directory partition that holds all the attributes for each directory partition object is called a replica. The replica on each domain controller has read and write attributes.
In Active Directory, changes can be made to the Active Directory database on any domain controller within the Active Directory environment. To overcome the limitations of the Windows NT domain environments illustrated earlier, each domain controller must include all information that is created or changed on any other domain controller. Active Directory replication ensures that the information or data between domain controllers remains updated and consistent. Replication is the process that ensures that changes made to a replica on one domain controller are transferred to replicas on the remainder of the domain controllers. It is Active Directory replication that ensures that Active Directory information hosted by domain controllers is synchronized.
The multimaster environment of Active Directory eliminates the domain controllers as single points of failure because an Administrator can perform changes to the Active Directory database on any domain controller, and these changes are replicated to the other domain controllers within the domain.

What Information is Replicated in Active Directory

n Active Directory, there are certain actions that are considered Active Directory replication triggers. The activities that trigger or initiate Active Directory replication is summarized below:

When an object is created.
When an object is deleted.
When an object is moved.
When an object is changed or modified.

Domain controllers typically contain the following directory partition replicas or naming context replicas:

Configuration: The configuration partition or naming context (NC) contains objects that relate to the logical structure of the forest, structure of the domain, and replication topology. Each domain controller in the forest contains a read/write copy of the configuration partition. Any objects stored in the configuration partition are replicated to each domain controller in each domain, and in a forest.
Domain: The domain partition or naming context (NC) contains all objects that are stored in a domain. Each domain controller in a domain has a read/write copy of the domain partition. Objects in the domain partition are replicated to only the domain controllers within a domain.
Schema: The schema partition or naming context (NC) contains objects that can be created in the Active Directory directory, and the attributes which these objects can contain. Domain controllers in a forest have a read-only copy of the schema partition. Objects stored in the schema partition are replicated to each domain controller in domains/forests.
Application: The application partition is a new feature introduced in Windows Server 2003. This partition contains application specific objects. The objects or data that applications and services store here can comprise of any object type excluding security principles. Security principles are Users, Groups, and Computers. The application partition typically contains DNS zone objects, and dynamic data from other network services such as Remote Access Service (RAS), and Dynamic Host Configuration Protocol (DHCP).

An Overview of Active Directory Replication Terminology, Concepts and Objects

In Active Directory, there are numerous concepts, and objects that are used to create a replication topology. These are described below:

Sites: A site can be defined as a grouping or set of Internet Protocol (IP) subnets that are connected by a highly reliable, fast and inexpensive link. This is usually a local area network (LAN) or metropolitan area network (MAN). Domains can have domain controllers in multiple sites. A site can have domain controllers from multiple domains. In Active Directory, sites have the following main roles or purposes:
- A site determines the closest domain controller at workstation logon.
- A site operates as a replication boundary. As a replication boundary, a site optimizes replication between sites because it can be used to improve on and more efficiently manage Active Directory replication.
- A site also functions as a resource locator boundary. Clients are only able to access resources that are accessible in a particular site.
Site Links: Site links are logical connections that are established between sites is Active Directory that define a path between these sites. A site link defines the direction of Active Directory replication between sites. You can use either RPC over IP or SMTP as the transport protocol for moving replication data over a site link. Site links are assigned the following:
- Cost: With replication, the concept of cost indicates the cost of the physical link between two Active Directory sites and is utilized to detail optimal connection paths btween one site and another site. When a site link is assigned a cost, the type of connection is taken into consideration. For replication, the lower costing links are used over higher costing links.
- Interval: Replication over a site link takes place at predetermined time intervals. When assigning the replication interval, it is important not to set the value to too high or too low. An exceptionally high value means that changes take a longer time to be replicated, while an exceptionally lower value means that replication occurs too regularly.
- Schedule: A replication schedule and interval are basically used together. An interval is associated with a schedule. A schedule deals with when the replication of data is going to occur.
Site link bridge: In Active Directory, you can use a site link bridge to link sites that share common Active Directory data but who do not have a site link. The data typically shared by these sites is the Application directory partition.
Connection objects: In Active Directory, domain controllers replicate with specific replication partners. The partners that domain controllers replicate with are defined by connection objects. Connection object enable data to be replicated in Active Directory because they define inbound replication paths. Domain controllers and their associated connections are defined in a topology map. The Directory Replication Agent (DRA) handles replication between domain controllers. The Directory Replication Agent uses the connection objects in the topology map to find out those partners that are relevant when replicating changes to directory partitions. The DRA sends a replication request to the partners of a domain controller when the domain controller needs to update its copy of Active Directory. Administrators can manually create connection objects, or they can leave these objects to be created by the Knowledge Consistency Checker (KCC). When the KCC creates connection objects, it is an automatic process. The KCC runs on all domain controllers in Active Directory. As an Administrator, you can create a manual connection object between any two domain controllers in a forest. If you want data to flow in two directions, you should create two connection objects. You can create manual connection objects between domain controllers in the same site or in different sites. The Knowledge Consistency Checker by default creates automatic connection objects. It references the site topology and then uses the information on sites and site links to automatically create connection objects. The KCC checks the site topology at regular intervals to determine whether the connection objects are still valid, and then changes connection objects based on its reviews. It is the KCC that is accountable for making certain that data in the directory partitions are replicated in sites. You can disable the automatic creation of connection objects on a per site and forest wide basis.
The Inter Site Topology Generator (ISTG): Intersite connection objects are created by the Inter Site Topology Generator (ISTG) and not the KCC. The first domain controller in a site has the role of Inter Site Topology Generator. There is only one ISTG within a particular site. It is the ISTG that is responsible for ensuring that the site has a replica of the configuration, domain and schema partitions.
SYSVOL data and the File Replication Service (FRS): The system volume contains scripts and group policies. SYSVOL data is hosted on every domain controller. Changes to SYSVOL are replicated to domain controllers within the same domain via File Replication System (FRS) replication. With FRS replication, the full file is replicated and not just the actual changes that were made to the file. This differs to Active Directory replication. With Active Directory only the changes that were made to Active Directory objects are replicated.
Replicatio methods/protocols: Active Directory replication can utilize one of two protocols to send replication data between domain controllers:
- Remote Procedure Call (RPC): This is the main protocol used by Active Directory to send replication data. RPC's encryption capabilities are beneficial for replicating data in Active Directory in the network.
- Simple Mail Transport Protocol (SMTP): SMTP is typically utilized for sending replication data in bulk, and for sending replication data over unreliable network connections.

Active Directory Replication Types

In Windows 2000 and Windows Server 2003, the types of Active Directory replication that can be defined are intrasite replication and intersite replication.

Active Directory Intrasite Replication

Intrasite replication in Active Directory takes place between domain controllers within the same site. This makes intrasite replication an uncomplicated process. When changes are made to the replica of Active Directory on one particular domain controller, the domain controller contacts the remainder of the domain controllers within the site. The domain controller checks the information it contains against information hosted by the other domain controllers. To perform this analysis, the domain controller utilizes logical sequence numbers. Intrasite replication utilizes the Remote Procedure Call (RPC) protocol to convey replication data over fast, reliable network connections. With intrasite replication, replication data is not compressed.

Active Directory Intersite Replication

Intersite replication takes place between sites. Intersite replication can utilize either RPC over IP or SMTP to convey replication data. This type of replication has to be manually configured. Intersite replication occurs between two domain controllers that are called bridgeheads or bridgehead servers. The role of a bridgehead server (BS) is assigned to at least one domain controller in a site. A BS in one site deals with replicating changes with other BSs in different sites. You can configure multiple bridgehead servers in a site. It is only these BSs that replicate data with domain controllers in different domains by performing intersite replication with its BS partners. With intersite replication, packets are compressed to save bandwidth. This places additional CPU load on domain controllers assigned the BS role. BSs should therefore be machines that have enough speed and processors to perform replication. Intersite replication takes place over site links by a polling method which is every 180 minutes by default.

Initiating Replication between Active Directory direct replication partners (forcing replication)

Active Directory usually automatically creates and deletes connection objects between domain controllers. There are cases though when you might need to manually create connection objects and then force Active Directory replication. You can utilize one of the following tools or methods to force replication:

Active Directory Sites and Services console
Repadmin
Replmon

Active Directory Replication Topology Options

The Active Directory replication topologies typically utilized are:

Ring Topology: With intrasite replication, the KCC creates a ring topology that defines the replication paths within a site. In a ring topology, each domain controller in a site has two inbound and outbound replication partners. The KCC creates the ring so that there is no greater than three hops between domain controllers in a site.
Full Mesh Topology: This topology is typically utilized in small organizations where redundancy is extremely important, and the number of sites is quite small. A full mesh topology is quite expensive to manage and is not scalable.
Hub And Spoke Topology: This topology is typically implemented in arge organizations where scalability is important and redundancy is less important. In this topology, one or multiple hub sites exist that have slower WAN connections to multiple spoke sites. The hub sites are usually connected to each another through high speed WAN connections.
Hybrid Topology: The hybrid topology is combination of any of the above topologies.

How to Define an Active Directory Replication Strategy

The replication strategy that you implement essentially determines when replication would occur and the manner in which Active Directory information is replicated. Designing an effective replication strategy involves the following steps:

Evaluating the actual physical connectivity of the network: This phase of planning typically involves determining the site links that are necessary in the network. You would need to identify your network connections, domain controllers and sites to determine this. You would need to determine which:
- Sites are connected by low speed unreliable connections – high costing connections.
- Sites are connected by fast reliable connections – low costing connections.
- Sites are connected by medium speed connections – medium costing connections.
Another component of this planning phase involves determining whether site link bridges need to be created. While planning what sites are needed, remember to include the possible future growth of the organization.
Determining the site link configuration parameters for every connection: The configuration parameters or values that need to be specified for each site link is summarized below:
- Site link name
- The transport protocol to be used for conveying replication data. This can be either RPC or SMTP.
- Site link cost: The default site link cost setting is 100. The value can range between 1 and 32,767.
- Replication interval or frequency
- Replication schedule or when replication should occur.
Determine the preferred bridgehead servers: Instead of using the preferred bridgehead server defined by the Knowledge Consistency Checker (KCC), you can choose to manually configure a preferred bridgehead server.
Determine whether site link transitivity should be disabled: If you choose to disable site link transitivity, you must manually create site link bridges between site links to ensure site link transitivity.

PKI Technologies

2011-06-03T02:30:00.000-07:00

PKI Technologies

Organizations need enhanced security for data and strong credentials for identity management. You can use certificates to secure data and manage identification credentials from users and computers both within and outside your organization.
A public key infrastructure (PKI) is the combination of software, encryption technologies, processes, and services that enable an organization to secure its communications and business transactions. The ability of a PKI to secure communications and business transactions is based on the exchange of digital certificates between authenticated users and trusted resources.
You can design a PKI solution to meet the following security and technical requirements of your organization:

Confidentiality. You use a PKI to encrypt data that is stored or transmitted.
Integrity. You use a PKI to digitally sign data. A digital signature helps you identify whether another user or process modified the data.
Authenticity. A PKI provides several authenticity mechanisms. Authentication data passes through hash algorithms, such as Shivest Hash Algorithm 1 (SHA1), to produce a message digest. The message digest is then digitally signed by using the sender’s private key to prove that the message digest was produced by the sender.
Nonrepudiation. When data is digitally signed, the digital signature provides proof of the integrity of the signed data and proof of the origin of the data. A third party can verify the integrity and origin of the data at any time. This verification cannot be refuted by the owner of the certificate that digitally signed the data.

PKI Technologies Architecture

The architecture of a PKI involves implementing various interdependent technologies and processes to make it possible to issue, validate, renew, and revoke certificates. These technologies include:

One of more servers running Certificate Services and that provide certificate enrollment, revocation and other certificate management services.
Active Directory directory service or another directory service that provides account management, policy distribution, and certificate publication services.
Domain controllers that can authenticate end users and computers when they request certificates.
Domain client computers and users, who request, receive, and use certificates for specific purposes. Although certificates can also be used by services and by non-domain clients, in most Windows PKI environments, domain users and computers are the primary recipients and users of certificates. In some cases, the domain client can be a subordinate CA that requests and receives a certificate authorizing it to issue certificates of its own.

The following figure illustrates the architecture of PKI technologies.
PKI Technologies Architecture

PKI Technologies Components

The key technology components of a PKI and their relation to the PKI architecture diagram are described in the following table.
Components of a PKI

Components	Description
Certificates	Provide the foundation of a PKI. Digital certificates are electronic credentials that are associated with a public key and a private key that an organization uses to authenticate users. Certificates are created on servers running Certificate Services and stored on clients and in a directory such as Active Directory.
Certificate templates	Can be used to define the content and purpose of a digital certificate, including issuance requirements; implemented extensions, such as application policy or extended key usage; and enrollment permissions for certificates that a CA issues. Certificate templates are stored in the Active Directory and used by enterprise CAs to provide the default attributes for a certificate.
Certificate Services	The part of the core operating system that allows a business to act as its own CA, and issue and manage digital certificates. Certificate Services includes tools to manage issued certificates, publish CA certificates and CRLs, configure CAs, import and export certificates and keys, and recover archived private keys.
CAs	Servers on which Certificate Services has been configured to issue, validate, and manage certificates. Windows Server 2003 supports multiple levels of a CA hierarchy and a cross-certified trust network. This includes offline and online CAs.
Certificate Revocation Lists	List of certificates that a CA considers no longer usable. Certificates have a specified lifetime, but CAs can reduce this lifetime by a process known as certificate revocation. Publishers can use any kind of directory service, including X.500, Lightweight Directory Access Protocol (LDAP), or directories in a specific operating system, including Active Directory, to store CRLs. Publishers can also publish CRLs on Web servers.
Certificate policy and practice statements	The two documents that outline how a CA and its certificates are to be used, the degree of trust that can be placed in these certificates, legal liabilities if the trust is broken, and so on. These documents can also define or impact PKI designs, operations, and usage, including how a CA is configured, how client requests are processed, and guidelines and procedures for revoking certificates.
Certificate policies	Configurable limitations on the scope of a certificate. Certificate policies can be implemented as required and allowed certification path length, the range of namespaces that are permitted or excluded by a qualified subordinate CA, the extent to which an organization trusts the identity presented in a certificate, and the applications that can be used in conjunction with certain certificates.
Certificate and CRL repositories	A directory service or other location where certificates are stored and published. In a Windows Server 2003 domain environment, the Active Directory is the most likely publication point for certificates issued by Windows Server 2003–based CAs.
PKI-enabled applications	Examples of PKI-enabled applications include: Encrypting File System (EFS), Microsoft Internet Explorer, Microsoft Money, Internet Information Services (IIS), Routing and Remote Access, Microsoft Outlook, and Microsoft Outlook Express. Also included are a variety of third-party applications that work with Windows 2000 and Windows Server 2003 Certificate Services.

PKI Technologies Scenarios

A PKI consists of one or more CAs that play specific roles. One or more CAs of each type can be combined in a CA hierarchy.

Roles in a CA Hierarchy

Each CA in a CA hierarchy is assigned a role, which is determined by the CA’s location in the CA hierarchy. Common roles in a CA hierarchy include a root CA, a policy CA, and an issuing CA.

Root CAs

A root CA is the highest CA in a CA hierarchy and is the trust point for all certificates that are issued by the CAs in the CA hierarchy. If a user, computer, or service trusts a root CA, they implicitly trust all certificates that are issued by all other CAs in the CA hierarchy.
A root CA is different from all other CAs in that it issues its own certificate. This means that the Issuer and Subject fields of the certificate contain the same distinguished name. A root CA only issues certificates to other CAs that are directly subordinate to it.

Policy CAs

A policy CA is typically located on the second-tier of a CA hierarchy, directly beneath the root CA. In this scenario, the root CA is often referred to as a parent CA, because the root CA issued a Subordinate Certification Authority certificate to the policy CA. In fact, any CA that issues a certificate to another CA is referred to as a parent CA. The CA that receives the certificate from a parent CA is known as a subordinate CA.
The role of a policy CA is to describe the policies and procedures that an organization implements to secure its PKI, the processes that validate the identity of certificate holders, and the processes that enforce the procedures that manage certificates. A policy CA issues certificates only to other CAs. The CAs that receive these certificates must uphold and enforce the policies that the policy CA defined.
It is not mandatory to use policy CAs unless different divisions, sectors, or locations of your organization require different issuance policies and procedures. However, if your organization requires different issuance policies and procedures, you must add policy CAs to the hierarchy to define each unique policy. For example, an organization can implement one policy CA for all certificates that it issues internally to employees and another policy CA for all certificates that it issues to non-employees.

Issuing CAs

An issuing CA is typically located on the lowest tier of a CA hierarchy. An issuing CA issues certificates to other computers, users, network devices, services, or other issuing CAs. An issuing CA is always online.
The parent CA for an issuing CA can be a root CA, a policy CA or another issuing CA. The issuing CA must enforce the policies and procedures that are described in the policy CA above the issuing CA in the CA hierarchy.

Types of CA Hierarchies

You can use one of two CA models: a root hierarchy or a cross-certification trust. Windows Server 2003 networks recognize and support both models.

Root Hierarchies

In a root CA hierarchy, all of the CAs in the organization’s CA hierarchy are chained to a common root CA. The following figure illustrates a root CA hierarchy.
Root CA Hierarchy
A root CA hierarchy:

Enhances security and scalability. It protects the upper layers of the CA hierarchy from network attacks by removing the upper layers of the CA hierarchy from the network.
Provides flexible administration to the CA hierarchy. You can use role separation to delegate CA management to separate administration groups in an organization.
Supports commercial CAs.All commercial CAs — such as VeriSign, GTE, Thawte, and RSA — implement trusted root CA hierarchies.
Supports most applications.Applications such as Microsoft Internet Explorer and Netscape Communicator support certificates that root CA hierarchies issue, as do IIS and Apache Web servers.

Cross-Certification Trusts

In a cross-certification trust, a CA in one organization’s root CA hierarchy issues a subordinate CA certificate to a CA in another organization’s CA hierarchy. The following figure illustrates a cross-certification hierarchy.
Cross-Certification Trust
A cross-certification trust:

Provides interoperability between businesses and between products. When cross-certification is implemented, the certificates are logically chained to the trusted root CA of the organization that is evaluating the presented certificate.
Joins disparate PKI domains. You can issue a Cross Certification Authority certificate from any CA in your organization’s hierarchy to any CA in a partner organization’s CA hierarchy.
Assumes complete trust of a foreign CA hierarchy. Cross-certification does not enforce any constraints on the certificates that a partner organization issues. You must implement qualified subordination to implement constraints on those certificates.

Active Directory Domain Services: Last Interactive Logon

2011-06-02T12:53:00.000-07:00

Active Directory Domain Services (AD DS) in the Windows Server® 2008 operating system introduces a new feature: last interactive logon. Last interactive logon information is available in domains that operate at the Windows Server 2008 domain functional level. It is also available in domain-joined Windows Server 2008 server computers and Windows Vista® client computers.

What does last interactive logon do?

Last interactive logon helps you record four key components of user logon information:

The total number of failed logon attempts at a domain-joined Windows Server 2008 server or a Windows Vista workstation
The total number of failed logon attempts after a successful logon to a Windows Server 2008 server or a Windows Vista workstation
The time of the last failed logon attempt at a Windows Server 2008 or a Windows Vista workstation
The time of the last successful logon attempt at a Windows Server 2008 server or a Windows Vista workstation

Why use last interactive logon?

Last interactive logon is useful if you want to see if someone is trying to perform a brute-force attack on the directory by trying to access an account and guessing the password.
In addition, you can use last interactive logon for compliance and auditing purposes by determining who is trying to access a user account and when these access attempts occur.

Where last interactive logon information is stored

Last interactive logon information is stored in four attributes of the user objects that are added to the schema when a domain operates at a Windows Server 2008 functional level:

msDS-FailedInteractiveLogonCount—The number of failed logon attempts at a Windows Server 2008 server or a Windows Vista workstation since the last interactive logon feature was enabled
msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon—The total number of failed interactive logons up until the last successful Ctrl-Alt-Del logon
msDS-LastFailedInteractiveLogonTime—A time stamp of the last failed logon attempt
msDS-LastSuccessfulInteractiveLogonTime—A time stamp of the last successful logon attempt at a Windows Server 2008 server or a Windows Vista workstation

Replication

Last interactive login information is updated on the domain controller that authenticates the user’s logon. The information is then replicated to every domain controller in the domain. In addition, as mentioned in the previous section, the information is stored in attributes that are assigned to user objects.
If a user account is authenticated by a read-only domain controller (RODC), the information is written to the user account that resides on the RODC. The information is also written to the nearest writeable domain controller. At the next scheduled replication, the information is then replicated from the writeable domain controller back to the RODC. This happens because the high-water mark and update sequence number are not updated on the RODC. Instead, they are updated on the writeable domain controller.

How last interactive logon information is reported

There are two ways to report last interactive logon information:

Write the information to the directory in AD DS

If last interactive logon information is enabled in a Group Policy object (GPO) with domain controllers in its scope of management, the last interactive logon information is written to the attributes that are listed in the previous Where last interactive logon information is stored section for all user accounts that are logging on to any domain controller in the domain.
Write the information to the AD DS directory, and display last interactive logon information to the user

If last interactive logon information is enabled in a GPO with domain controllers in its scope of management and in a GPO with server and client computers in its scope of management, last interactive logon information is written to the AD DS directory as previously described as well as displayed to the user after he or she logs on to the workstation.

Information that appears at the server and workstation

When a user logs on to a computer for the first time after the last interactive logon feature is turned on—in a GPO with domain controllers in its scope of management and with Windows Server 2008 servers or Windows Vista client computers in its scope of management—the following message appears after the user logs on:
“<User Account>”
“This is the first time you have interactively logged on to this account.”
On subsequent logons, the user receives the following message:
“<User Account>”
Successful Logon
“The last time you interactively logged on to this account was: <time>”
Unsuccessful Logon
“The last unsuccessful interactive logon attempt on this account was: <time>”
“The number of unsuccessful interactive logon attempts since your last interactive logon: <number>”

How to configure last interactive logon

You configure last interactive logon through a GPO. You must configure the following setting for the GPO with domain controllers in its scope of management if you want to report last interactive logon information to the directory service:
Computer Configuration| Policies | Administrative Templates | Windows Components | Windows Logon Options | Display information about previous logons during user logon = Enabled
If you want to display last interactive logon information to the user, you must configure this setting for both the GPO with domain controllers in its scope of management as well as any GPO with Windows Server 2008 and Windows Vista client computers in its scope of management.

Configuration notes

Note the following considerations for configuration of last interactive logon:

For last interactive logon to operate correctly, the domain functional level must be set to Windows Server 2008. If this is not the case, users will not be able to log on to their computers and they will receive the following message:

“Security policies on this computer are set to display information about the last interactive logon. Windows could not retrieve this information. Please contact your network administrator for assistance.”
If you enable last interactive logon on Windows Server 2008 and Windows Vista domain-joined computers and you do not enable this feature in a GPO with domain controllers in its scope, users will not able to log on to the system.
Only Windows Server 2008 and Windows Vista computers display last interactive logon information to users. All other operating systems ignore this feature.
Last interactive logon does not report from which computer the logon attempts occurred because last interactive logon information is stored in the user account properties. To determine from where the logon attempts occurred, you must check the security logs of the domain controllers.

Active Directory Domain Services: Last Interactive Logon

2011-06-02T12:49:00.000-07:00

What does last interactive logon do?

Last interactive logon helps you record four key components of user logon information:

The total number of failed logon attempts at a domain-joined Windows Server 2008 server or a Windows Vista workstation
The total number of failed logon attempts after a successful logon to a Windows Server 2008 server or a Windows Vista workstation
The time of the last failed logon attempt at a Windows Server 2008 or a Windows Vista workstation
The time of the last successful logon attempt at a Windows Server 2008 server or a Windows Vista workstation

Why use last interactive logon?

Where last interactive logon information is stored

Last interactive logon information is stored in four attributes of the user objects that are added to the schema when a domain operates at a Windows Server 2008 functional level:

msDS-FailedInteractiveLogonCount—The number of failed logon attempts at a Windows Server 2008 server or a Windows Vista workstation since the last interactive logon feature was enabled
msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon—The total number of failed interactive logons up until the last successful Ctrl-Alt-Del logon
msDS-LastFailedInteractiveLogonTime—A time stamp of the last failed logon attempt
msDS-LastSuccessfulInteractiveLogonTime—A time stamp of the last successful logon attempt at a Windows Server 2008 server or a Windows Vista workstation

Replication

How last interactive logon information is reported

There are two ways to report last interactive logon information:

Write the information to the directory in AD DS

If last interactive logon information is enabled in a Group Policy object (GPO) with domain controllers in its scope of management, the last interactive logon information is written to the attributes that are listed in the previous Where last interactive logon information is stored section for all user accounts that are logging on to any domain controller in the domain.
Write the information to the AD DS directory, and display last interactive logon information to the user

If last interactive logon information is enabled in a GPO with domain controllers in its scope of management and in a GPO with server and client computers in its scope of management, last interactive logon information is written to the AD DS directory as previously described as well as displayed to the user after he or she logs on to the workstation.

Information that appears at the server and workstation

How to configure last interactive logon

Configuration notes

Note the following considerations for configuration of last interactive logon:

For last interactive logon to operate correctly, the domain functional level must be set to Windows Server 2008. If this is not the case, users will not be able to log on to their computers and they will receive the following message:

“Security policies on this computer are set to display information about the last interactive logon. Windows could not retrieve this information. Please contact your network administrator for assistance.”
If you enable last interactive logon on Windows Server 2008 and Windows Vista domain-joined computers and you do not enable this feature in a GPO with domain controllers in its scope, users will not able to log on to the system.
Only Windows Server 2008 and Windows Vista computers display last interactive logon information to users. All other operating systems ignore this feature.
Last interactive logon does not report from which computer the logon attempts occurred because last interactive logon information is stored in the user account properties. To determine from where the logon attempts occurred, you must check the security logs of the domain controllers.

Hyper-V: How To Initiate a Live Migration using Windows PowerShell

2011-06-02T12:45:00.000-07:00

Hyper-V: How To Initiate a Live Migration using Windows PowerShell

You can initiate Live migration using Windows PowerShell scripts for failover clustering. This is one of the steps documented in Hyper-V: Using Live Migration with Cluster Shared Volumes in Windows Server 2008 R2 (http://technet.microsoft.com/en-us/library/dd446679(WS.10).aspx#BKMK_initiateLM)

To initiate a live migration using Windows PowerShell

Open Windows PowerShell. Click Start, point to All Programs, click Windows Powershell 2.0, and then click Windows Powershell 2.0.

The Failover Clustering feature must be installed on the computer on which you are starting the Windows PowerShell session. Or, you can use Remote Server Administration Tools for Windows® 7 to run the PowerShell session.

To install the Failover Clustering feature, type:

Add-Module FailoverClusters

Type:

Get-Cluster "<Cluster Name>" | Move-ClusterVirtualMachineRole -Name "<VM group name>" -Node "<Destination node name>"
Where:

<Cluster Name> is the name of the cluster that the virtual machine is included in.
<VM group name> is the virtual machine resource group.
<Destination node name> is the name of the destination node to which you would like to move the virtual machine using live migration.

Understanding and comparing the Hyper-V architecture

2011-06-02T12:43:00.000-07:00

Hypervisor architecture

History of virtualization at Microsoft

Everything began in February 2003 when Microsoft acquired a company that was already on the market since 1988 called Connectix. This company had a solution that could virtualize operating systems. For those who didn't know was surprising, because it was possible to do multiple tests of the functionality of the operating system (OS), but a virtual form within an existing OS. What is interesting is that virtualization technology is not new. True virtual environments, already existed in large Main Frames of the 1960s that could simulate a virtual environment, several virtual machines as the IBM model I44. In September 2004 Microsoft released Virtual Server 2005, a server with support for virtual machines (VM), but this had some hardware limitations, virtual systems could use only one processor x86 and maximum 3.6 GB of memory per VM. Running in parallel with these solutions virtual Intel and AMD launched its processors with hardware virtualization support, baptized of Intel-VT and AMD-V. Virtual Server 2005 R2 SP1 was launched and has already provided support to the new processor technologies, providing better performance, however all hardware call was sent from VMs to the virtual machine monitor (VMM), it forwarded these calls to the host operating system and then to the Windows kernel. Only after that the VM Hardware being accessed in this way, a processor switching between physical and virtual machine. It was for this reason that the Virtual Server 2005 does not used 100% of the power provided by the hardware virtualization from Intel and AMD.

In Windows 2008 Microsoft released Hyper-V and the Hyper-V Server. The latter would be a free version of the operating system only with Hyper-V role enabled. Hyper-v supports x86 and x64 VM, and 64 GB of memory and up to 4 processors per virtual machine, using the entire capacity hardware virtualization. In the table below is apparent difference between solutions:

Table 1 – differences between virtual server, hyper-v and hyper-v Server

Compared to its predecessor Virtual Server 2005, the Hyper-V differential associated with hardware virtualization are VMs with more memory and processor support, so the speed and security.

Virtual Machine Monitor (VMM)

To explain in a way more advanced and technical difference between virtualization types used by the virtual server and hyper-v, is important to understand a little of the VMM.

It is responsible for the creation, preservation, access to system resources and VM management. There are three types of implementation: VMM type 2 hybrid VMM and VMM type 1.

VMM type 2 VMM hybrid VMM type 1

Figure 1 – types of VMM

VMM type 2 runs above the host operating system. The hybrid type runs parallel to the host system, type this used by Virtual Server 2005 R2, which has used the technology of AMD-V and Intel-VT, but without the hypervisor. The third, type 1, is a Hypervisor-based solution, used by the hyper-v, providing performance and with a series of components for communication of VMs to hardware.

Structure of Hypervisor

Windows Server 2008 with Hyper-v provides a structure for the Hypervisor-based virtualization of type 1 (VMM), I believe that this should not be news to anyone since it is normal to read or hear this in almost every place where the subject is Microsoft Virtualization. When you install Windows Server 2008 the Hyper-V is not installed automatically. The OS without Hyper-v has direct access to hardware and Hypervisor structure does not exist, as Figure 2.

After operating system installation you need to add the function of hyper-v in Server Manager (this function is only available in Windows Server 2008 x 64).

Figure 2 – Windows 2008 without Hyper-V

After installation of Hyper-V and rebooting the machine, OS suffers several amendments. The file responsible for Windows boot (Winload.exe) loads the driver hvboot.sys. This driver checks which processor is running, and whether it supports virtualization. After this process is loaded the hypervisor image file (Hvix64.exe for Intel-VT or Hvax64.exe to AMD -V). Only after this the system boots, thereby creating a single standard called Parent Partition, where you made the first virtualization and it runs Windows 2008. Sounds strange, but is that the operating system that you raise after the hyper-v virtual also was installed. The virtual machines that are added after the hyper-v are created in partitions call Child Partitions. Is the Hypervisor that manages these partitions and control access them to hardware.

Hardware virtualization

Another interesting approach is subject to hardware virtualization. Without this there are only 4 specific hardware of rings, called Rings processor, which define the level of access privilege to the processor. The privilege is the ring 0, used by the Windows kernel and Ring 3 is typically used in user level, amounting to a total of 4: ring 0, 1, 2 and 3.

When installing the hyper-v is created a ring that runs on a privileged mode called privileged or ring -1. This ring causes the hypervisor rode in a greater privilege that the Windows kernel allowing any operating system continue to be used for ring 0 and users application running in ring 3. In Figure 2 you can analyze Parent and Child partitions, in addition to processing rings.

Figure 3 – Hypervisor, Rings and partitions

Virtualization Stack

All creation and management of virtual machines of hyper-v are made by a series of virtual devices and software components that work together called Virtualization Stack used in both the Parent and Child partition. Some of them are: Virtualization Service Provider (VSP), Virtualization Service Client (VSC) Virtualization Infrastructure driver (VID) and virtual machine bus (VMBus). This series of software and components work with Hyper-v management in conjunction with the hypervisor. The VSP is a software component that is in the Parent partition and that controls I/O requests on behalf of the virtual machines. Already the VMBus is responsible for data transfer and delivery of services between Parent and Child partitions for a dedicated channel available between the VSCs and VSPs. The VSC uses the VMBus for the communication of the VSP partitions Child up to the functioning of synthetic drivers that run on the Child partitions.

The VID uses some APIs for communication between the Parent partition to the Hypervisor. The access and the instructions of the Parent partition APIs to Hypervisor are called Hypercalls. The VID is applied in two levels: kernel-level with the file VID.sys in ring 0 and User level by VID.ll file in Ring 3.

How to start in Directory Service Restore Mode (DSRM) in Windows Server 2008 and Windows Server 2008 R2

2011-06-02T12:41:00.000-07:00

Here are two methods to enter Directory Services Restore Mode (DSRM) in Windows Server 2008 or Windows Server 2008 R2:

From the Desktop use the graphical user interface (GUI) Msconfig tool. Click Start. In Start Search, type msconfig and then click OK. On the Boot tab, select Safe Boot, and then click Active Directory repair. (see attached figure)
From a command prompt, use bcdedit. The command: bcdedit /set safeboot dsrepair enables DSRM upon restart. When you want to restart in normal mode, run the following command: bcdedit /deletevalue safeboot

This posting is provided "AS IS" with no warranties, and confers no rights.

Introducing Active Directory Recycle Bin

2011-06-02T12:38:00.000-07:00

Accidental deletion of Active Directory objects is a common occurrence for users of Active Directory Domain Services (AD DS) and Active Directory Lightweight Directory Services (AD LDS).
In Windows Server 2008 Active Directory domains, you could recover accidentally deleted objects from backups of AD DS that were taken by Windows Server Backup. Or you could recover deleted Active Directory objects through tombstone reanimation. The drawback to the authoritative restore solution was that it had to be performed in Directory Services Restore Mode (DSRM) during which the domain controller being restored had to remain offline. And the problem with tombstone reanimation was that reanimated objects' link-valued attributes (for example, group memberships of user accounts) were physically removed and non-link-valued attributes were cleared and not recovered.
Windows Server 2008 R2 Active Directory Recycle Bin enhances your ability to preserve and recover accidentally deleted Active Directory objects by preserving all link-valued and non-link-valued attributes of the deleted Active Directory objects. With the Active Directory Recycle Bin enabled, the objects are restored in their entirety to the same consistent logical state that they were in immediately before deletion.
There are a couple of special considerations:
1. By default, Active Directory Recycle Bin is disabled. To enable it, you must first raise the forest functional level of your AD DS or AD LDS environment to Windows Server 2008 R2. This in turn requires that all domain controllers in the forest or all servers that host instances of AD LDS configuration sets be running Windows Server 2008 R2.
2. In Windows Server 2008 R2, the process of enabling Active Directory Recycle Bin is irreversible. After you enable Active Directory Recycle Bin in your environment, you cannot disable it.
For further information, such as the Active Directory Recycle Bin scenario overview and the detailed steps on how to recover a single or multiple deleted objects (using ldp.exe or the Active Directory PowerShell snap-in), see What's New in AD DS: Active Directory Recycle Bin (http://go.microsoft.com/fwlink/?LinkId=141392) and Active Directory Recycle Bin Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=133971).
This posting is provided "AS IS" with no warranties, and confers no rights.

PKI Design "Brief Overview"

2011-06-02T12:35:00.000-07:00

PKI Design Brief Overview

Before you configure a Public Key Infrastructure (PKI) and certification authority (CA) hierarchy, you should be aware of your organizations security policy and certificate practice statement (CPS). If your organization does not have such policy statements, you should consider creating them. For more information on policy statements, see Example Policy Statements in this article. When you do plan your CA hierarchy for your organization's PKI, you can use the following table to get an idea of the type of hierarchy and CAs to implement.

Design Option	Best for	Pros	Cons
Enterprise root CA on a domain controller online	> Lab environments only when PKI design is not a priority. > Resources severely constrained (worst case scenario).	+ Fewer Windows Server operating system (OS) licenses and configurations.	- Configuration dependencies make domain controller maintenance and restore complex.- CA is online and more susceptible to compromise.
Enterprise root CA online	> Small organizations with limited security needs.> Environments that don’t have high security needs and do not want to manage an offline system. > Large companies with limited certificate needs, such as internal SSL online only.	+ Easy to manage, uses templates, integrates with Active Directory Domain Services (ADDS)	- CA is online an more susceptible to compromise. - Cannot revoke online CA if compromised - More difficult than multi-tier CA hierarchies to expand
Enterprise root CA offline	Not recommended.	+ When offline the CA is not exposed to network-based attacks	- Administrative difficulty and uncommon configuration, which may not function properly or reliably with no known benefit over using an offline Standalone Root CA. - Unlikely that an Enterprise Root CA could be installed offline, unless Windows Server 2008 R2 is used with offline domain join. Such a use of offline domain join has not been tested and may not be supported.
Standalone offline root CA	Secure environment, multiple Issuing CAs.	+ Provides security and management of online CAs. Allows environments to have a single point to trust all CAs in the company. + Helps control physical and logical control to CA	- Easy to forget about and allow CDP/AIA to expire and break PKI. Expensive – requires dedicated hardware or virtual computer that is infrequently used. - More complex and requires greater skill level to integrate in an Active Directory Domain Services (AD DS) environment.
Two-tier CA hierarchy	Most environments that do not have a need to create security boundaries in their CA architectures.	+ No unnecessary offline systems. + Less CAs to manage and renew offline	- No ability to restrict subordinate CAs or administrators. - Should include a Hardware Security Module (HSM), which comes at additional cost.
Three-tier CA hierarchy	Very large and expansive PKI environments with segmented CAs or separate groups that will manage CAs and need to be restricted.	+ Ability to restrict CAs from issuing certs that should not. For example, a perimeter network (also called DMZ) CA should not issue Smart cards. + Allows greatest flexibility of PKI .	- Middle tier often never utilized and is wasted. Extra computer or virtual machine, OS, and HSM expense. - Another computer to maintain in an offline state.

Local and Domain User Password Policy

2011-06-02T12:33:00.000-07:00

We know that we can set domain password policies through a group policy tied to the domain NC head. We know that up until 2008, this policy becomes the singular effective password policy for all domain user accounts. This means that even if we create a group policy and tie it to an OU lower down in the structure, say an Admins OU, this will not affect domain user policy - even for thos admin accounts in that OU. So, natively, we can’t set one policy for our users and another, more restrictive policy for our admins. However, what is often unknown or overlooked is that password policy set down at the lower OU may actually have an impact.
If the policy in the lower OU applies only to users, then the password policy settings will be useless (remember, password policy settings are applied in the computer portion of policy) – even if we enable Loopback Processing. But, if the password policy applies to computers (workstations or servers), then the policy does have an impact.
Group policy settings become part of the effective local policy. The password policy settings for local policy affect any local accounts; and every Windows machine has a local accounts database. The password policy settings in the group policy will overwrite any locally configured settings and the accounts in the local SAM will be subjected to these domain-based password policy settings.
I occasionally have customers request that their local accounts have a different password policy than the domain (say, a longer password requirement). To apply that to some contained set of workstations, simply create a policy linked to the OU or a parent OU of these workstations and configure the password policy settings there. It will have no impact on the domain password policy but it will affect local accounts on the workstations.

DNS Command Line and GUI Scenarios Clarified

2011-06-02T12:32:00.000-07:00

I suggested that they do the following:

Set it so DNS enables scavenging on all zones by default, so that it's enabled when the zone is created.
Set all of the zones that weren't set to scavenge, to do so.
Set it so DNS zones are automatically set to secure only. ;)
Set all of the zones that weren't set to be secure only, to do so.

Below is what I told them to do to accomplish those simple goals, however since some of the wizards don't explain exactly what they do, and since you can get inconsistent or unexpected results, if you don't know what to expect, I thought I'd clarify a bit.
In order to meet the first goal, to set all newly created zones to scavenge upon creation, I told them to run the following command, obviously changing <server> to their server names.
Dnscmd <server> /config /defaultagingstate 1
Note: By default it's set to 0. Also, unlike some other commands you can't just type the command without a parameter to see the status.
Also, it's important to note that the /defaultagingstate switch is server specific, so if a zone is created on another DC/DNS server where it's not set to 1, it won't automatically be set to scavenge, unless that command is run for that server as well, or it's enabled via the GUI.
Essentially, that command is the command line equivalent to right clicking the server, selecting "Set Aging/Scavenging for all Zones", checking the "Scavenge Stale Resource Records" box, and then clicking OK.

When you click OK, it'll take you to another screen and then you'd click OK again, leaving the "apply these settings to the existing Active Directory-integrated zones" check box unchecked.
You can also define default no-refresh and refresh intervals (that will be modified on the same screen) by using the /defaultnorefreshinterval and /defaultrefreshinterval switches. Those are also server-level settings and the value is a hex value. Obviously, if you have a small number of DNS servers then the GUI method is easier for changing all of the defaults, but if you have a lot of DNS servers, then you'll want to use the command line or using that via a batch file or script.
The one thing that I'm not a big fan of is that the wizard doesn't explain very well what it is exactly that you're enabling. When selecting "Set Aging/Scavenging for all Zones", to me that sounds like a one time deal where you just run through the wizard.
Also of note, if you define those settings, and then want to run through the wizard to age all of the zones with the same settings, the confirmation screen will be blank, as depicted below and changes will not be propagated to all zones as you might expect:

For example, lets say that 20 new zones were created on another server, but that server doesn't have default aging settings, and later you realize that aging isn't enabled. Well lets say that you go back to the DC that does have default aging settings and you try to use the "Set Aging/Scavenging for all Zones" wizard to set all of the zones to age with your defined settings...you come to realize that it doesn't work.. You see the blank confirmation window above saying that no changes will be made (though it doesn't jump out and say that).
Now, if on that same DC, where you your default settings defined, if you change intervals away from 3 in this example, to 5, then the confirmation will reflect that change for the no-refresh and refresh intervals...but that only changes those intervals (if you check the "apply these settings to the existing Active Directory-integrated zones")...it will not check the "Scavenge Stale Resource Records" box for the newly created zone that was created from the other DC. That's implicitly evident on the confirmation screen though, but you'd need to know what was missing in that screen to know that the "Scavenge Stale Resource Records" check box wouldn't be checked.

If you want to make changes to the no-refresh and refresh intervals, as well as enabled "Scavenge Stale Resource Records" for all zones, as the Wizard implies, after already having these settings defined, you can do that by changing the no-refresh and refresh values, as well as unchecking the "Scavenge Stale Resource Records" box and click ok. In this case, you would not want to check "apply these settings to the existing Active Directory-integrated zones". After you save the changes, you would go back into the wizard, define the settings that you do want applied to all zones, and then click OK.

Notice that this time, we see in the confirmation box, that it will also check the "Scavenge Stale Resource Records" box for the zone, where before that implicitly left out. If we check "apply these settings to the existing Active Directory-integrated zones", now this will apply to all zones as depicted on the confirmation screen, satisfying the second goal. Alternatively, you could make changes from another DNS server that has no defaults defined and that will also do it, among other ways.
To satisfy the third goal of setting the zones to be secured by default...you do absolutely nothing...its set that way by default.
They could have had it set to be unsecured for any number of reasons. In my mind, either they went out of their way to check the "allow both non-secure and secure dynamic updates" button for some requirement that they had (but as far as I know there is no requirement for that in their environment), or those were secondary zones that were created to "migrate" DNS from an old domain that's now collapsed, where they "promoted" those secondary zones to Primary/AD-integrated zones to preserve records, and the zone security settings were also preserved. In this case the old zones were un-secure. Regardless of the reason, they wanted to set them all to be secure.
So to satisfy the last requirement of setting all of the zones to being secure without having to manually do it, we just ran the following command, again changing <server> to their server name:
dnscmd <Server> /config ..AllZones /AllowUpdate 2
When we ran the command however, it threw an error: DNS_ERROR_INVALID_ZONE_TYPE Regardless of the error, the command still worked. But now I had to know why it threw the error...
I only found one internal article that discussed the error when running the same exact command, but they said the cause was due to the customers' server having secondary zones on it. In testing it in my lab, it also threw the same error. I don't have any secondary zones however, nor does my customer, so that was out. The only thing that I noticed when testing in my lab was that when I did a dnscmd /enumzones after running the "dnscmd <Server> /config ..AllZones /AllowUpdate 2" command to set the zones to secure, the only zone that didn't update was the built in TrustAnchors zone (for DNSSEC)...and being that it was my lab and I didn't care, I deleted it. It immediately went away when killing it in ADSI, but it didn't go away when re-enumerating the zones, it just said "Aging Down". Eventually it went away when re-enumerating (though I may have cycled the DNS service) and after that the command ran without error.

DNS Registration with NetDiag

2011-06-02T12:30:00.000-07:00

!!! WARNING: IT Systems Administrator blasphemy ahead !!! Actually, here it is right here: I know that NetDiag is a staple tool for systems administrators but I’ve never been a big consumer of the tool and that’s mostly because I just don’t care for it. There is some great functionality in the tool but a lot of it can be found in other tools without all of the excess effort and output. The other thing is that there are some limitations and known issues which often misdirects administrator’s focus in troubleshooting. For escalation support data collection (like Microsoft’s CSS), it can be very helpful, but for day-to-day administration, I personally think it’s just too much.
Still, there’s a feature of NetDiag that I learned about not long ago that I can’t deny is pretty cool. Ever had a DC that just wasn’t registering it’s records like you know it should? Maybe you’ve even cycled the NETLOGON service and the record still just isn’t registering. When you open the NETLOGON.DNS file on the DC, you see that it should be registering all of the correct records but still, for whatever reason, it isn’t; and you need it to now!
So, here’s where NetDiag comes in. If the NETLOGON.DNS file is complete with all of the expected records (which it should be unless you’re waiting on replication or process completion), running NetDiag /fix will actually register all missing records on your behalf.
I know it’s a simple functionality but as any system administrator knows, a simple problem like name (or service) resolution can be the source of major outages and dissatisfaction. So that’s pretty awesome, huh? Well, for someone who doesn’t care much for NetDiag, I thought it was pretty cool when I was told about it.

Virtual PC 2007 v Windows Virtual PC

2011-06-02T12:29:00.000-07:00

If you are looking for an unbiased view of Windows Virtual PC, don’t read this! I love(d) Virtual PC 2007 (henceforth VPC2K7) and was very excited to hear about a new version because there are some things that I wanted to see fixed (like the addition of USB support and 64-bit guest OS support). When Windows Virtual PC released (henceforth WVPC), I was excited about some of the enhancements but very, very disappointed with what was lost. Here’s a brief look at what was lost and why it’s not cool.
So, the new WVPC is heavily driven by Terminal Services functionality which brings to bear the very cool Windows XP mode. WVPC also has support for USB drives which is nice as well. It makes transferring files between machines a little bit easier…since we don’t have Shared Folders anymore.
And that’s where we’ll start with the losses…Shared Folders. I loved Shared Folders. It was so nice to setup a local tools directory on the host machine and just dump all of my wares there. I could even install and run most of the Support and Resource Kit Tools directly in this folder. That saved me some precious space in my VMs and on my computer because I didn’t have to duplicate those files on every VM. In the old VPC2K7, it was so easy to set up Shared Folders to map a network drive to my tools directory on the host machine.

You can still kinda do this today in WVPC but how you do it is a little bit different and less reliable. Because WVPC is based on Terminal Services, you can carry your host drives through to the guest operating system. This isn’t nearly as nice for two reasons. One, it requires that the Integration Components are active (different than just being installed) on the guest OS. Two, it carries the whole drive through so I have to browse to my tools directory – which can be a pain if it is nested deep in the drive.

Logon in VPC2K7 is very straightforward. You are essentially presented with a console window to which anyone can log on just as if they were sitting in front of a terminal. That means that you can logon with a blank password if your policy permits. If you are allowed to logon locally, then you can log on to the box. Straightforward.

Logging on to WVPC is more complicated. It requires that you have Terminal Services logon rights. If you want to leverage Integration Components then you have to logon with an account that has a password. This can be very frustrating when you are trying to test conditions with blank passwords or for normal users (that wouldn’t have these rights). Also frustrating when you want to test Terminal Services logon.

Drag-n-drop in VPC2K7 is probably one of my favorite functionalities. For those few that may not know, it provides the ability for me to simply copy a file from my host machine to my guest machine (or in reverse) simply by dragging the file over the VM like it was folder. This can also be done from the guest machine to the host machine.

In place of drag-n-drop, WVPC has…nothing. I’ve heard that it was taken out because it was a security concern. When you use drag-n-drop, it uses a clipboard behavior to copy the file between source and destination. Apparently, the file stays on the clipboard and this is the security risk. Okay, fine, I can see if this was an issue if it was on Virtual Server or Hyper-V but this is a desktop virtualization technology. In the scenario where this would be an issue for most Virtual PC users, it would be a bigger issue that someone was on my desktop in the first place.

Changing common settings in VPC2K7 is very easy as well with the context icons at the bottom of the guest window. These context icons make it easy to quickly change or add Shared Folders, add media to the DVD drive, or adjust the network settings. All of this functionality I used very often.

WVPC requires me to go through more menus to get to these guest machine settings. Not sure why we go backwards in ease of use as we go forward with the application version. Perhaps this has something to do with the fact that WVPC is based on Terminal Services but I am not sure why.

I could live with all of this if WVPC added one thing – support for 64-bit guest operating systems. Why is it that it leverages hardware-assisted virtualization but it does not support 64-bit operating systems? This is even more unforgivable now that 2008 R2 has released and it is available as 64-bit only. This means that I can’t use Microsoft own desktop virtualization software to test a Microsoft operating system. It leaves me with two choices – VMWare Workstation if I want to use my Windows 7 box, or Hyper-V. BTW, it’s kinda funny but VMWare is actually touting the fact that they have drag-n-drop functionality with VMWare Workstation.
C’mon Microsoft, don’t tie the hands of your admins. I understand the value of Windows XP Mode and it is cool but don’t take away what I had. Or, if the functionality is mutually exclusive, then give me a choice how to use it. I personally don’t need the application virtualization ability but I do miss all of the perks of Virtual PC 2007. And for your own sake, don’t make it so I can’t even use your virtualization technology to support your own operating system. At least give me a testing only version like you did for Exchange 2007 (which you should be doing anyway so that you don’t make me upgrade my test lab just to run your new OS – and no, I don’t want to hear how cheap hardware is now – I want to use the hardware I have already invested in).

Group Policy for Beginners

2011-06-02T12:25:00.000-07:00

Group Policy for Beginners

If you are an IT pro who has never used Group Policy to control computer configurations, this white paper is for you. Group Policy is the essential way that most organizations enforce settings on their computers. It is flexible enough for even the most complex scenarios; however, the essential features are easy to use in simple scenarios, which are more common.

This white paper is an introduction to Group Policy. It first provides an overview of what you can do with Group Policy, and then it describes essential concepts that you must know. For example, what is a Group Policy object (GPO)? What does inheritance mean? With the fundamentals out of the way, this white paper provides step-by-step instructions, with plenty of screenshots, for the most common Group Policy tasks.

Note

This guide is for Group Policy novices. As much as possible, it uses plain English to describe Group Policy concepts in simple ways. Group Policy pros should see Group Policy Planning and Deployment Guide on TechNet for more technically detailed information.

For a web version of this document, see Group Policy for Beginners in the Windows 7 Technical Library.

Overview of Group Policy

Group Policy is simply the easiest way to reach out and configure computer and user settings on networks based on Active Directory Domain Services (AD DS). If your business is not using Group Policy, you are missing a huge opportunity to reduce costs, control configurations, keep users productive and happy, and harden security. Think of Group Policy as “touch once, configure many.”

The requirements for using Group Policy and following the instructions that this white paper provides are straightforward:

· The network must be based on AD DS (that is, at least one server must have the AD DS role installed). To learn more about AD DS, see Active Directory Domain Services Overview on TechNet.

· Computers that you want to manage must be joined to the domain, and users that you want to manage must use domain credentials to log on to their computers.

· You must have permission to edit Group Policy in the domain.

Although this white paper focuses on using Group Policy in AD DS, you can also configure Group Policy settings locally on each computer. This capability is great for one-off scenarios or workgroup computers, but using local Group Policy is not recommended for business networks based on AD DS. The reason is simple: Domain-based Group Policy centralizes management, so you can touch many computers from one place. Local Group Policy requires that you touch each computer—not an ideal scenario in a large environment. For more information about configuring local Group Policy, see Local Group Policy Editor on TechNet.

Windows 7 enforces the policy settings that you define by using Group Policy. In most cases, it disables the user interface for those settings. Additionally, because Windows 7 stores Group Policy settings in secure locations in the registry, standard user accounts cannot change those settings. So, by touching a setting one time, you can configure and enforce that setting on many computers. When a setting no longer applies to a computer or user, Group Policy removes the policy setting, restoring the original setting and enabling its user interface. The functionality is all quite amazing and extremely powerful.

Note

Standard user accounts are user accounts that are members of the local Users group and not the local Administrators group. They have a restricted ability to configure system settings. Windows 7 better supports standard user accounts than earlier Windows versions, allowing these accounts to change the time zone, install printers, repair network connections, and so on. Deploying standard user accounts is a best practice, and you do so by simply not adding user accounts to the local Administrators group. Windows 7 automatically adds the Domain Users group to the local Users group when you join the computer to the domain.

Essential Group Policy Concepts

You can manage all aspects of Group Policy by using the Group Policy Management Console (GPMC). Figure 1 shows the GPMC, and this white paper will refer to this figure many times as you learn about important Group Policy concepts.

Figure 1. Group Policy Management Console

You start the GPMC from the Start menu: Click Start, All Programs, Administrative Tools, Group Policy Management. You can also click Start, type Group Policy Management, and then click Group Policy Management in the Programs section of the Start menu. Windows Server 2008 and Windows Server 2008 R2 include the GPMC when they are running the AD DS role. Otherwise, you can install the GPMC on Windows Server 2008, Windows Server 2008 R2, or Windows 7 as described in the section “Installing the GPMC in Windows 7,” later in this white paper.

Group Policy objects

GPOs contain policy settings. You can think of GPOs as policy documents that apply their settings to the computers and users within their control. If GPOs are policy documents, then the GPMC is like Windows Explorer. You use the GPMC to create, move, and delete GPOs just as you use Windows Explorer to create, move, and delete files.

In the GPMC, you see all the domain’s GPOs in the Group Policy objects folder. In Figure 1, the callout number 1 shows three GPOs for the domain corp.contoso.com domain. These GPOs are:Accounting Security. This is a custom GPO created specifically for Contoso, Ltd.

· Accounting Security. This is a custom GPO created specifically for Contoso, Ltd.

· Default Domain Controller Policy. Installing the AD DS server role creates this policy by default. It contains policy settings that apply specifically to domain controllers.

· Default Domain Policy. Installing the AD DS server role creates this policy by default. It contains policy settings that apply to all computers and users in the domain.

Group Policy Links

At the top level of AD DS are sites and domains. Simple implementations will have a single site and a single domain. Within a domain, you can create organizational units (OUs). OUs are like folders in Windows Explorer. Instead of containing files and subfolders, however, they can contain computers, users, and other objects.

For example, in Figure 1 you see an OU named Departments. Below the Departments OU, you see four subfolders: Accounting, Engineering, Management, and Marketing. These are child OUs. Other than the Domain Controllers OU that you see in Figure 1, nothing else in the figure is an OU.

What does this have to do with Group Policy links? Well, GPOs in the Group Policy objects folder have no impact unless you link them to a site, domain, or OU. When you link a GPO to a container, Group Policy applies the GPO’s settings to the computers and users in that container. In Figure 1, the callout number 1 points to two GPOs linked to OUs:

· The first GPO is named Default Domain Policy, and this GPO is linked to the domain corp.contoso.com. This GPO applies to every computer and user in the domain.

· The second GPO is named Accounting Security, and this GPO is linked to the OU named Accounting. This GPO applies to every computer and user in the Accounting OU.

In the GPMC, you can create GPOs in the Group Policy objects folder and then link them—two steps. You can also create and link a GPO in one step. Most of the time, you will simply create and link a GPO in a single step, which the section “Creating a GPO,” later in this white paper, describes.

Group Policy Inheritance

As the previous section hinted, when you link a GPO to the domain, the GPO applies to the computers and users in every OU and child OU in the domain. Likewise, when you link a GPO to an OU, the GPO applies to the computers and users in every child OU. This concept is called inheritance.

For example, if you create a GPO named Windows Firewall Settings and link it to the corp.contoso.com domain in Figure 1, the settings in that GPO apply to all of the OUs you see in the figure: Departments, Accounting, Engineering, Management, Marketing, and Domain Controllers. If instead you link the GPO to the Departments OU, the settings in the GPO apply only to the Departments, Accounting, Engineering, Management, and Marketing OUs. It does not apply to the entire domain or the Domain Controllers OU. Moving down one level, if you link the same GPO to the Accounting OU in Figure 1, the settings in the GPO apply only to the Accounting OU, as it has no child OUs. In the GPMC, you can see what GPOs a container is inheriting by clicking the Group Policy Inheritance tab (callout number 1 in Figure 2).

Figure 2. Group Policy inheritance and precedence

So, what happens if multiple GPOs contain the same setting? This is where order of precedence comes into play. In general, the order in which Group Policy applies GPOs determines precedence. The order is site, domain, OU, and child OUs. As a result, GPOs in child OUs have a higher precedence than GPOs linked to parent OUs, which have a higher precedence than GPOs linked to the domain, which have a higher precedence than GPOs linked to the site. An easy way to think of this is that Group Policy applies GPOs from the top down, overwriting settings along the way. In more advanced scenarios, however, you can override the order of precedence.

You can also have—within a single OU—multiple GPOs that contain the same setting. Like before, the order in which Group Policy applies GPOs determines the order of precedence. In Figure 2, you see two GPOs linked to the domain corp.contoso.com: Windows Firewall Settings and Default Domain Policy. Group Policy applies GPOs with a lower link order after applying GPOs with a higher link order. In this case, it will apply Windows Firewall Settings after Default Domain Policy. Just remember that a link order of 1 is first priority, and a link order of 2 is second priority. You can change the link order for a container by clicking the up and down arrows as shown by callout number 2 in Figure 2.

Note

As you are probably realizing by now, Group Policy is a remarkably versatile tool. However, Group Policy provides the opportunity to make things overly complicated. In simple environments, such as labs and small businesses, there is nothing wrong with linking all of your GPOs to the domain. Keep it simple. There should be a justification for complication. In Figure 1, if you wanted to create a GPO and link it only to the Engineering and Marketing OUs, the justification should be that the GPO contains settings that apply only to those two departments and should not be applied to any other department. If you cannot make this justification, then keep things simple by linking the GPO one time to the domain.

Group Policy Settings

To this point, you have learned about GPOs. You have learned that GPMC is to GPOs and OUs as Windows Explorer is to files and folders. GPOs are the policy documents. At some point, you are going to have to edit one of those documents, though, and the editor you use is the Group Policy Management Editor (GPME), which Figure 3 shows. You open a GPO in the GPME by right-clicking it in the GPMC and clicking Edit. Once you are finished, you simply close the window. The GPME saves your changes automatically, so you do not have to save.

Figure 3. Group Policy Management Editor

In Figure 3, callout numbers 1 and 2 point to Computer Configuration and User Configuration, respectively. The Computer Configuration folder contains settings that apply to computers, regardless of which users log on to them. These tend to be system and security settings that configure and control the computer. The User Configuration folder contains settings that apply to users, regardless of which computer they use. These tend to affect the user experience.

Within the Computer Configuration and User Configuration folders, you see two subfolders (callout numbers 3 and 4 in Figure 3):

· Policies.Policies contains policy settings that Group Policy enforces.

· Preferences.Preferences contains preference settings that you can use to change almost any registry setting, file, folder, or other item. By using preference settings, you can configure applications and Windows features that are not Group Policy–aware. For example, you can create a preference setting that configures a registry value for a third-party application, deletes the Sample Pictures folder from user profiles, or configures an .ini file. You can also choose whether Group Policy enforces each preference setting or not. However, standard user accounts can change most preference settings that you define in the User Configuration folder between Group Policy refreshes. You can learn more about preference settings by reading the Group Policy Preferences Overview.

When you are first learning Group Policy, most of the settings that you will configure will be in the Administrative Templates folders. These are registry-based policy settings that Group Policy enforces. They are different from other policy settings for two reasons. First, Group Policy stores these settings in specific registry locations, called the Policies branches, which standard user accounts cannot change. Group Policy–aware Windows features and applications look for these settings in the registry. If they find these policy settings, they use the policy settings instead of the regular settings. They often disable the user interface for those settings as well.

Second, administrative template files, which have the .admx extension, define templates for these settings. These templates not only define where policy settings go in the registry but also describe how to prompt for them in the GPME. In the Group Policy setting that Figure 4 shows, for example, an administrative template file defines help text, available options, supported operating systems, and so on.

Figure 4. Group Policy setting

When you edit a policy setting, you are usually confronted with the choices that callout numbers 1 to 3 indicate in Figure 4. In general, clicking:

· Enabled writes the policy setting to the registry with a value that enables it.

· Disabledwrites the policy setting to the registry with a value that disables it.

· Not Configured leaves the policy setting undefined. Group Policy does not write the policy setting to the registry, and so it has no impact on computers or users.

Generalizing what enabled and disabled means for every policy setting is not possible. You can usually read the help text, shown in callout number 5, to determine exactly what these choices mean. You must also be careful to read the name of the policy setting. For example, some policy settings say, “Turn on feature X,” whereas other policy settings say, “Turn off feature Y.” Enabled and disabled have different meanings in each case. Until you are comfortable, make sure you read the help text for policy settings you configure.

Some policy settings have additional options that you can configure. Callout number 4 in Figure 4 shows the options that are available for the Group Policy refresh interval policy setting. In most cases, the default values match the default values for Windows. As well, the help text usually gives detailed information about the options you can configure.

Group Policy Refresh

As you learned in the previous section, GPOs contain both computer and user settings. Group Policy applies:

· Computer settings when Windows starts.

· User settings after the user logs on to the computer.

Group Policy also refreshes GPOs on a regular basis, ensuring that Group Policy applies new and changed GPOs without waiting for the computer to restart or the user to log off. The period of time between these refreshes is called the Group Policy refresh interval, and the default is 90 minutes with a bit of randomness built in to prevent all computers from refreshing at the same time. If you change a GPO in the middle of the day, Group Policy will apply your changes within about 90 minutes. You don’t have to wait until the end of the day, when users have logged off of or restarted their computers. In advanced scenarios, you can change the default refresh interval.

Note

You can manually update Group Policy any time by using the command Gpupdate.exe. For example, after updating a GPO, you might want to refresh Group Policy on a computer in order to test your changes without waiting for the Group Policy refresh interval. For step-by-step instructions, see the section titled “Updating Clients” later in this white paper.

Essential Group Policy Tasks

You have now learned the essential Group Policy concepts. You know that a GPO is like a document that contains policy settings. You manage GPOs by using the GPMC and you edit them by using the GPME.

You also know that you link GPOs to AD DS sites, domains, and OUs to apply the GPOs’ settings to those containers. Domains, OUs, and child OUs inherit settings from their parents, but duplicate settings in GPOs linked to child OUs have precedence over the same settings in GPOs linked to parent OUs, which have precedence over GPOs linked to the domain, and so on.

You also know that within a site, domain, or OU, the link order determines the order of precedence (the smaller the number, the higher the precedence). Last, you have an essential understanding of how to edit GPOs and what types of settings they contain.

Now that you know the essential concepts, you are ready to learn the essential tasks. This section describes how to create, edit, and delete GPOs. It describes many other tasks, as well. For each task, you’ll find an explanation of its purpose and step-by-step instructions with screenshots at each step.

Note

A feature of the Microsoft Desktop Optimization Pack (MDOP) called Advanced Group Policy Management (AGPM) extends Group Policy with new capabilities such as offline editing, version control, and role-based delegation. Any organization can benefit from using AGPM to manage Group Policy. For more information about AGPM, see Enhancing Group Policy through change management.

Creating a GPO

You create a GPO by using the GPMC. There are two ways to create a GPO:

· Create and link a GPO in one step.

· Create a GPO in the Group Policy objects folder, and then link it to the domain or OU.

The instructions in this section describe how to create and link a GPO in one step.

You can start with a blank GPO, which the instructions describe, or you can use a starter GPO. Starter GPOs are an advanced topic that you can learn about in Working with Starter GPOs.

To create and link a GPO in the domain or an OU

1	In the GPMC, right-click the domain or OU in which you want to create and link a GPO, and click Create a GPO in this domain, and Link it here.
2	In the Name box on the New GPO dialog box, type a descriptive name for the GPO, and then click OK.

Editing a GPO

In the GPMC, you can open GPOs in the GPME to edit them within any container. To see all of your GPOs, regardless of where you link them, use the Group Policy objects folder to edit them.

To edit a GPO in the domain, an OU, or the Group Policy objects folder

1	In the left pane of the GPMC, click Group Policy objects to display all the domain’s GPOs in the right pane. Alternatively, you can click the domain or any OU to display that container’s GPOs in the right pane.
2	In the right pane of the GPMC, right-click the GPO that you want to edit, and click Edit to open the GPO in the GPME.
3	In the GPME, edit the Group Policy settings that you want to change, and close the GPME window when finished. You do not have to save your changes, because the GPME saves your changes automatically.

Linking a GPO

If you create and link GPOs in one step, you do not have to manually link GPOs to the domain or OUs. However, if you create a GPO in the Group Policy objects folder or unlink a GPO and want to restore it, you will need to manually link the GPO. The easy way to link a GPO is to simply drag the GPO from the Group Policy objects folder and drop it onto the domain or OU to which you want to link it.

To link a GPO to a domain or OU

1	In the GPMC, right-click the domain or OU to which you want to link the GPO, and then click Link an Existing GPO.
2	In the Select GPO dialog box, click the GPO that you want to link to the domain or OU, and then click OK.

Unlinking a GPO

You unlink a GPO when you no longer want to apply it to the domain or OU (or its child OUs). You can later restore the link, as the section titled “Linking a GPO” described.

Unlinking a GPO from a domain or OU does not delete the GPO. It only deletes the link. After unlinking a GPO, you can still find it in the Group Policy objects folder in the GPMC.

To unlink a GPO from a domain or OU

1	In the GPMC, click the domain or OU containing the GPO that you want to unlink.
2	Right-click the GPO that you want to unlink from the domain or OU, and click Delete.
3	In the Group Policy Management dialog box, click OK.

Deleting a GPO

Deleting a GPO is not the same as unlinking a GPO from a domain or OU. You delete GPOs within the Group Policy objects folder. Doing so removes not only the links but also the GPO itself.

Note

Consider backing up the GPO before deleting it. The section titled “Backing Up GPOs” describes how to back up GPOs. The section titled “Restoring GPOs” describes how to restore them from a backup.

To delete a GPO from the Group Policy objects folder

1	In the GPMC, click the Group Policy objects folder.
2	In the right pane of the GPMC, right-click the GPO that you want to delete, and click Delete.
3	In the Group Policy Management dialog box, click Yes to confirm that you want to delete the GPO and its links.
4	In the Delete dialog box, confirm that the deletion was successful, and click OK.

Updating Clients

While editing, testing, or troubleshooting GPOs, you do not need to wait for the Group Policy refresh interval (90 minutes, by default). You can manually update Group Policy on any client computer by running Gpupdate.exe. Gpupdate.exe supports many command-line options, which you can learn about by typing gpupdate.exe /? in a Command Prompt windows In most cases, however, you can follow the instructions in this section to update Group Policy.

To manually update Group Policy by using Gpupdate.exe

1	Click Start, type cmd, and press Enter to open a Command Prompt window.
2	At the Command Prompt, type gpupdate and press Enter. Gpupdate.exe will update any changed settings. You can force Gpupdate.exe to update all settings, whether or not they have changed recently, by typing gpupdate /force and pressing Enter.

Backing Up GPOs

Backing up important files is an important practice, and GPOs are no exception. If you erroneously change or accidentally delete a GPO, you can quickly restore it from a backup. By using the GPMC, you can back up GPOs to any location.

To back up a GPO to a folder

1	In the GPMC, click the Group Policy objects folder.
2	Right-click the GPO that you want to back up, and click Back Up.
3	In the Location box of the Back Up Group Policy object dialog box, type the path of the folder to which you want to back up the GPO. You can also click Browse to choose a folder. Also, in the Description box, type a brief description of the GPO, and then click Back Up.
4	In the Backup dialog box, confirm the results and click OK.

Restoring GPOs

By using the GPMC, you can restore any previous version of a GPO that you have backed up. The instructions in this section describe how to restore one or more GPOs from a backup folder.

To restore a previously backed-up GPO

1	In the GPMC, click the Group Policy objects folder to see the GPOs in the domain.
2	Right-click the Group Policy objects folder, and click Manage Backups.
3	In the Backup location list of the Manage Backups dialog box, click a backup location that you’ve previously used. You can also click Browse to choose a folder containing GPO backups.
4	In the Backed up GPOs list, choose one or more GPOs that you want to restore, and click Restore. If you see multiple versions of each GPO and want to see only the most recently backed-up version of each GPO, select the Show only the latest version of each GPO check box.
5	In the Restore dialog box, confirm that the operation was successful, and click OK.

Installing the GPMC in Windows 7

Windows Server 2008 and Windows Server 2008 R2 include the GPMC when they are running the AD DS role. Otherwise, you can install the GPMC on Windows Server 2008, Windows Server 2008 R2, or Windows 7. You install the GPMC by downloading the Remote Server Administration Tools for Windows 7 with Service Pack 1 (SP1) and installing either of the following files on the computer:

1. Windows6.1-KB958830-x64-RefreshPkg.msu. Install this package on x64 computers, including those running Windows Server 2008 R2.

2. Windows6.1-KB958830-x86-RefreshPkg.msu. Install this package on x86 computers.

Installing the update only adds the feature to Windows. You must also turn on the Group Policy Management Tools feature using Programs and Features in the Control Panel. The instructions in this section describe how to install the update as well as how to enable the Group Policy Management Tools.

To install the Remote Server Administration Tools for Windows 7 with SP1

1	Run either of the following files that you previously downloaded: 1. Windows6.1-KB958830-x64-RefreshPkg.msu 2. Windows6.1-KB958830-x86-RefreshPkg.msu Then, click Yes to install the update.
2	On the Read these license terms (1 of 1) page, review the license terms, and if you accept, click I Accept.
3	On the Installation complete page, click Close.

To turn on the Group Policy Management Tools feature

1	Click Start, type windows features, and click Turn Windows features on or off in the Control Panel section of the Start menu.
2	In the Windows Features dialog box, select the Group Policy Management Tools check box, and click OK. Group Policy Management Tools is under Remote Service Administration Tools, Feature Administration Tools.