Configuration Manager clients Auto-Site Assignment with DirectAccess IPv6 #sysctr


Currently I’am implementing DirectAccess (DA) infrastructure for a Dutch customer. First I must say I am very satisfied with its operation of DA. Part of DA is remote management (Eventlog, RDP, SCCM, DPM) of Internet DA clients from Intranet, which is pretty nice working as well!

I was wondering how SCCM client auto-site assignment works through DA. Is it a supported scenario and how does I have to define site boundaries as auto site-assignment is based on? Does I have to define my DA server IPv6 or corporate IPv6 prefix as SCCM IPv6 site boundary? Yes, yes, yes!!! Auto-site assignment is supported by DA and works pretty straight foward as it does for your intranet clients :-)

But first some background of IPv6 prefix.

If you have an IPv4 address on the internal facing interface of UAG DirectAccess server, DirectAccess assumes that you don’t have IPv6 deployed in your organization. An IPv6 address is 128 bit – the first 64 bits are the IPv6 “prefix” (which is similar to the IPv4 network ID) and the last 64 bits represent the IPv6 Host ID (similar to the IPv4 host ID). The UAG DirectAccess wizard configures the network prefix information using a 6to4 prefix based on the public IP address bound to the UAG DirectAccess server.

Behind the scenes UAG DirectAccess automatically configures the following prefixes using 6to4 notation: 

  1. 2002:WWXX:YYZZ:8000::/49 as the organizational prefix
  2. 2002:WWXX:YYZZ:8000::/64 as the ISATAP prefix
  3. 2002:WWXX:YYZZ:8001::/96 as the NAT64/DNS64 prefix
  4. 2002:WWXX:YYZZ:8100::/56 as the IP-HTTPS prefix

If you have an IPv6 address on the internal facing interface of UAG DirectAccess server, DirectAccess assumes that you have IPv6 deployed in your organization and therefore you need to enter three different IPv6 prefixes. Organization, IP-HTTPS and NAT64/DNS64 prefix.

As DirectAccess clients can use different IPv6 translation methods to connect to your DirectAccess server, all IPv6 prefixes must be defined as IPv6 site boundary’s enabling auto-site assignment. If you don’t, you might be at risk that auto-site assignment for one or more IPv6 translation methods will fail.

Hereby a number of examples of SCCM clients connected by different translation methods in relation to auto-site assignment.

DirectAccess client scenario connected by Teredo.

DirectAccess client scenario connected by IP-HTTPS.

An interesting question here (similar to boundaries that define VPN connections) is whether to configure these boundaries as fast or slow. There’s no right or wrong answer here, it depends on the throughput and reliability of the DA connection (which in turn depends on the Internet connection) and your preferred behavior for installing software updates and software distribution packages. I mention it because we do see customers reporting this as a problem – documented in “Clients Connecting over VPN Cannot Install Software Updates or Run Advertisements” from http://technet.microsoft.com/en-us/library/bb694288.aspx.

Used sources:

http://technet.microsoft.com/en-us/library/dd857387.aspx

http://blogs.technet.com/b/edgeaccessblog/archive/2009/10/13/deep-dive-into-uag-directaccess-ipv6-and-directaccess.aspx

http://social.technet.microsoft.com/Forums/en-US/configmgribcm/thread/25c1b962-130d-45da-a54d-fad54894a4c6/#409abefe-0d64-4c73-a3af-bc47803919a8

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s