Many of us have seen the problem. We have configured our laptops to use Direct Access and we never see them again. The ConfigMgr 2012 client is installed but has never received it's policy or reported correctly.
This is the dreaded ConfigMgr client that has never received policy.
Only two actions.
What is the problem? The problem is that ConfigMgr is not allowed to send a policy to these devices as they do not belong to any of the known boundaries. The good news it that this is easy to fix. We have to configure an IPv6 boundary.
It's easy to get the information we need. Open the properties of one of your Direct Access clients.
See the IPv6 Prefixes.
Create a boundary for each IPv6 prefix.
New boundaries.
Restart the SMS Agent Host on the client to speed things up. Now examine the PolicyAgent.log file.
We see activity.
The policy is now being downloaded to the client.
Success - healthy client
See here for additional tip for finding your IPv6 Prefix.
I wanted to make one comment. I found in the locationservices log file that the Directaccess client was apart of the same boundary as the Directaccess server and since that site was in a boundary group I was able to receive policy and download packages. Why would the Directaccess client show its site as where the DA server is especially when there is no IPV6 scope for that site?
ReplyDeletePerhaps it was in the same boundary as the DA server when it was directly connected to the LAN.
DeleteThat statement is not true: "The problem is that ConfigMgr is not allowed to send a policy to these devices as they do not belong to any of the known boundaries"
ReplyDeleteBoundaries/groups have nothing to do with that. A client can receive policies just fine once it is assigned to a site even if there are no boundary/groups defined at all. But don't ask me why it fixed your problem.
Thanks Torsten. That is a mystery.
DeleteSite assignment is different in 2012 as it is not needed.
DeleteDid you not put the Site Assignment in the Client first? Or were you relying on Auto assignment from the Boundary that did not exist?
A manual install of the client pushing the SMSSITECODE and MP might have worked, no?
If i do Get-RemoteAccess | select ClientIPv6Prefix on the directaccess server i only get one ipv6 prefix. in SCCM i see two ipv6 prefixes. I noticed one of those prefixes is for Teredo tunneling. We only use IP-HTTPS so the ipv6 prefix you get on the directaccess server is the one to add not the other ipv6 prefix unless you use Teredo.
ReplyDelete