Today (Tuesday) is the first (real) day on Teched Europe in Berlin. We will continue to post information from a lot of sessions throughout the week. We will focus on Forefront, Active Directory, Virtualization, Lync and some bits and pieces of other topics.

Explore Secure Collaboration Using Identity Federation in Forefront UAG Service pack 1

Service Pack 1 for Forefront UAG RTM is going to be released in December 2010.

Examples of features that is included in Sp1:

• ADFS v2 Integration
• Enhanced Direct access deployment and Operation
  • One-time-password support
  • Integrated NAP for simplified Endpoint policy enforcement
  • RMS server publishing
  • Exchange 2007 and Exchange 2010 are supported in coexistence with UAG
  • UAG and ADFS 2.0
    • UAG as AD FS proxy
    • Single Sign on even for legacy applications
    • Health policies are applied to partner users
    • Claims-based Authentication and Authorization

A legacy application in this session means applications that are not Claims-aware.

With AD FS and UAG you don´t need to reengineer old applications to get it to work, that for example uses Kerberos.

You can publish and use Claims to the UAG, UAG then uses a shadow user with Kerberos in for example the internal network. The ticket is sent between UAG and DC if you use Active Directory. The framework is configured in AD FS.

There are monitoring and auditing capabilities.

A couple of these features are enabled with only AD FS 2.0 but UAG publishes a nice portal in front of it.

UAG supports only passive clients like web browser or applications that simulate passive clients.

Question:

Do you need a separate firewall in front of the UAG?

Answer:

It´s Microsoft best practice to have a separate firewall although UAG have TMG.

Impact of cloning and Virtualization on Active Directory Domain Services

Scenario 1:

Clone a domain joined computer (VHD).

Can the cloned (copied) computer co-exist with the new computer?

It will work at first, but because of password requirements (computer objects also got passwords in a domain), when the first of the computers changes the password. Then the other one will be in trouble because it has the old password. The time to failure is based on the policies applied.

Always use sysprep when you are deploying a new computer.

Scenario 2:

You cannot clone from the same VHD as you have cloned to a DC. When you do DCPromo the domain SID is based on the original computer SID.

Do not, domain join a VHD that you have created a DC with. Local SID will have the same SID as the domain.

Scenario 3:

You will not be able to configure a trust between two domains that has the same SID. If you had cloned DC in domainA and cloned DC in domainB of the same VHD.

So always use sysprep when deploying computers. Do not just copy a VHD.

Same problem is on all virtualization platforms.

Best practice from Microsoft when using virtual DCs. Always keep 1-2 physical DC´s.

Advanced Group Policy Management 4.0 (AGPM 4.0)

Features:

• Offline editing of GPO
• Compare settings between GPOs (Difference report).
  • What was added, changed or removed.
  • Delegation of roles
    • Editor, Approver, Reviewer, Full control
    • Workflow:
      • Create a workflow for your changes in GPOs like:
      • (Offline) Control-> Checked out-> edit->Check in->Request->reporting->(Production) Deployment
    • Recycle bin:
    • You may restore deleted GPOs
    • Search filtering:
      • What is does
      • What it doesn´t do
    • Multi Forest Support
      • You can export and import the GPO

To setup AGPM you need to set it up on a separate server than the DC. It will than hold a copy of all GPOs.

The license is included in MDOP (Microsoft Desktop Optimization Pack) and cannot be purchased separately.

When you have deployed AGPM. Always use AGPM when editing GPOs. Because if you change it on the DC directly it will be overwritten the next time you publish it from AGPM.

Deep Dive on Designing a BranchCache Infrastructure

BranchCache have two different types of configurations:

• Distributed Cache
  • Uses clients in the branch office
  • Hosted Cache
    • Uses a dedicated server in the branch office

If you want to prelude the cache you can do that by scripting.

NLB (or physical load balancing) works also. Be sure you configure the load balanced server the same way. They must have the same Server Secret key.

The data that is transferred from the central site is divided into 64 bit blocks. This will ease your network on the WAN.

Cached data is stored in the clear, but it can be protected with Bitlocker or EFS.

Protocols:

SMB and HTTP is enabled out of the box. Even HTTPS is available because of the layer in the stack the BranchCache is operating.

If you are a developer you need to check out Peer Distribution on MSDN. It is a public API that you can build your application with so you can use the BranchCache features.

If you want to deploy this you should use GPO and link them to Sites in Active Directory. This will solve potential problems when users travel with their laptops. They will get the GPO that applies on the site they are logging in from.

Mixed mode:

You cannot have both configurations (Distributed and Hosted) on the same branch office.

Disaster Recovery by Stretching Hyper-V Clusters Across Sites

Regarding Multi Site Clustering, Microsoft said that they have a fully automated solutions and that the competitors doesn´t.

The biggest concern in a Disaster Recovery scenario is the dependence on people.

Windows 2008 R2 added support for Multiple Subnet clustering.

This is highly dependent on DNS. To enable faster failover you can use:

• RegisterallprovidersIP
• HostRecordTTL

Solution 1:

 Local failover First

• Configure local failover first high availability.
• Cross site failover for disaster recovery.
• Minimum of two servers.

 Solution 2:

Stretch VLANs

• Deploying a VLAN minimizes time for fail over. No new IP is applied, so therefore no change in DNS. No need for DNS to update and replicate.

Sol3: Abstraction in Networking Device

A network device that uses 3rd IP address. The client uses the device to connect to the services on the VM.

Live migration and CSV are not dependant but complimentary.

Cross subnet failover

• Use DHCP
• Static- can be solved by script
  • Example: look for errors in the cluster logs to the see if a fail over has occurred. Then update the IP settings and DNS.

Best practice to use DHCP

Quorum

There are four different setups of Quorum.

• Disk only (not recommended)
• Node and disk majority
• node majority
• node and file share majority

 Node majority must be uneven.

If you have 2 servers in SiteA and 3 servers in SiteB. If the entire Site B is unavailable you can force Quorum by command in Powershell (R2)

Start-clusternode -fixquorum or fq

once majority achieved, it drops out of forced quorum.

multi-site with file share witness

A 3rd site is the best setup.

Complete resiliency and automatic recovery from the loss of one site.

It uses file lock on the file share on 3rd site and the cluster will still work, if connection between SiteA and SiteB breaks.

For more info take a look these documents at Microsoft.com:

• Design guide deployment guide/checklist
• Multi-site Clustering Content