Direct Access Troubleshooting: Failed to connect to domain sysvol share

Hi, I've been setting up DirectAccess on windows server 2012 r2, using the single interface setup and have successfully connected to the intranet passing all important troubleshooting tests.
Now when troubleshooting the internet connection I am facing the following error:
Failed to connect to domain sysvol share
Here is the stack trace:
7/11/2014 12:46:18μμ[P:1340T:1] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TreeViewHandler] Info: Added ChildNode CertTestsNodeChild3.
7/11/2014 12:46:18μμ[P:1340T:1] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TreeViewHandler] Info: RootNode CertTestsNode found at index 4.
7/11/2014 12:46:18μμ[P:1340 T:1] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TreeViewHandler] Info: TheRootNode CertTestsNode has already 4 ChildNodes.
7/11/2014 12:46:18μμ[P:1340 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.InfraTunnelChecker] Info: Enter CheckSysvolShare - check the availability of the domain sysvol share.
7/11/2014 12:46:18μμ[P:1340 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.InfraTunnelChecker] Info: Trying to enumerate \\premiernic.com\sysvol\premiernic.com\Policies.
7/11/2014 12:46:18μμ[P:1340 T:1] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TreeViewHandler] Info: AddedChildNode CertTestsNodeChild4.
7/11/2014 12:46:18μμ[P:1340 T:1] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TreeViewHandler] Info: RootNode CertTestsNode found at index 4.
7/11/2014 12:46:18μμ[P:1340 T:1] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TreeViewHandler] Info: The RootNode CertTestsNode has already 5 ChildNodes.
7/11/2014 12:46:18μμ[P:1340 T:1] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TreeViewHandler] Info: AddedChildNode CertTestsNodeChild5.
7/11/2014 12:46:18μμ[P:1340 T:1] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TreeViewHandler] Info: About to add a new RootNode to the TreeView object.
7/11/2014 12:46:18μμ[P:1340 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.InfraTunnelChecker] ERROR: AnException occurred while connecting to the domain sysvol share. Message: The network path was not found.
7/11/2014 12:46:18μμ[P:1340 T:1] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TreeViewHandler] Info: Added new RootNode: InfraTunnelTestsNode. The list has now 6 nodes.
7/11/2014 12:46:18μμ[P:1340 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm] Info: Finished running IPsec Infrastructure Tunnel tests.
To troubleshoot I run:
"netsh dns show state"
- machine location correctly shows as outside corporate network
"netsh namespace show effectivepolicy"
- neither entries show Certification Authority.
- .premiernic.com lists ipv6 addresses for DNS servers, cy-da-01.premiernic.com does not
- proxy settings are correct
- in both cases IPSec is disabled
"ipconfig /all"
- Shows Teredo Tunneling used as ipv6 transition technology
"nltest /dsget:
- getting dc name failed, no such domain
Anyone got any ideas what may be going wrong?

Hi Steven, thanks for your answer.
When connected to the internet, i can ping the IPV6 DNS server addresses. When I try nslookup <aninternalFQDN> <IPV6DNS> i get a time-out. Same applies when testing the same commands from DirectAccess server.
Note that now, when looking at operation status, I see DNS as not operational and not responding to requests.
Finally, I check my server security logs for IPSec and find the following error (code 4653).
IPSec Main Negotiation failed
Failure location: Local computer
Failure reason: No Policy Configured
Verifying the infrastructure tunnel
Following the guide provided in the link, i first check whether the client can successfully create the tunnel. As expected I am able to see all the expected client policies in connection security rules(pt.3).
However, when I look at Monitoring \ Connection Security (pt.4) i don't see DirectAccess Policy-ClientToDnsDc (but
I do see directaccess policy-ClientToDNS64NAT64PrefixExemption).
I then run netsh
advfirewall monitor show currentprofile where I only see my public profile with my ISP settings, which to my understanding is correct.
When I run netsh advfirewall monitor show mmsa main mode shows computer cert and user ntlm for auth.
When I run netsh advfirewall monitor show qmsa quick mode shows remote address as expected.
When I run nltest /dsgetdc: /force on client machine i get "getting dc name failed", however from my directaccess server to dc command completes successfully.
Verifying the intranet tunnel
When running net view \\IntranetFileServer I
see an offline share (would be online if accessible). Web interface wont load for the same system.
When running netsh advfirewall monitor show mmsa and qmsa everything is as expected.
Conclusions
Couldn't find anything in either server firewall rules or gateway that would be blocking dns.
I think the culprit is the following:
IPSec negotiation failed - no policy found (on server)
Missing DirectAccess Policy - ClientToDnsDc
I've done a couple of gpupdates on both client and server, and double checked gpresult. Nothing seems out of order, except no refernce to to clienttodnsdc. Still nothing.
Anybody?

Similar Messages

Win8.1 Direct Access Client Stuck at "Connecting"

I'm experimenting with Direct Access in a lab setting with 1 client and 3 2012 R2 servers. The client is running Windows 8.1 Enterprise.
The client is always able to connect to the Direct Access server but is unable to ping or connect to the 2 servers that don't have RAS installed. Moreover, this behavior migrates to whichever server is running Remote Access Server: So, if I remove the role
and install on another server, the client is able to communicate with the new server, but not the old.
The connection from the client to the server is via IP-HTTPS (only option available to me in this environment). The client is able to reliably determine when it's on the Internet versus the intranet. However, when on the Internet, it stays in a "Connecting"
state and never connects, but I'm still able to access the DA server.
Does anyone have any ideas on how to resolve this?

I managed to resolve the issue. I'm posting here in the hope that this may help another newbie to DA.
Here's what caused my issue: As I mentioned, this was a lab environment where the limited number of machines were fulfilling multiple roles. In particular, the DA Server was also a backup domain controller running DNS. In my research, I came across a comment
on http://directaccessguide.com that mentioned that the DA Server runs DNS64 to support clients; that made me suspicious that the regular DNS server was in some way conflicting. And, in fact, before this server was
made a backup DC, DA was functioning just fine. Removing the backup DC role resolved the issue.
So the takeaway is this: Don't run the regular DNS service on the DA Server; if you do, you will get DA client connectivity only to the DA Server.

Access Manager Failed to Connect to Directory Server

Dear All,
I have problem with Directory Server connection in Access Manager. This happened in Production site, all application that integrated with Oracle Access Manager (OAM) for Single Sign On are not accessible after the Directory Server connection problem occur in OAM. The problem has only started occurring suddenly, before it the all service including the OAM and Directory Server is running well. Below are the error messages that appear in WebGate log file (ohs1.log) and OAM log file (oblog.log) :
>> OHS/WebGate (ohs1.log) :
[2014-01-21T09:25:12.0053+07:00] https://community.oracle.com/OHS https://community.oracle.com/OHS-9999 https://community.oracle.com/apache2entry_web_gate.cpp host_id: <WEBGATE_HOSTNAME> [host_addr:10.10.254.178] [ecid: 004w76rlRYt0NuapxKL6iW0000sE001oGY] The host and port from the requested URL could not be found in the Policy database. Check if the corresponding directory service is up.
>> OAM (Oblog.log):
2014/01/15@03:12:23.833746 [30573 30606 | tel:30573%20%20%2030606] DB_RUNTIME ERROR 0x000008C1 ../ldap_connection_mngr.cpp:443 "Failed to connect to directory server" lpszHost<LDAP_HOSTNAME_VIA_LOADBALANCER> port<LDAP_PORT_VIA_LOAD_BALANCER>
The OAM using the Load Balancer between the LDAP Directory Server to OAM's component. When the error appears, there are no problem with the Load Balancer and all of Directory Sever services is up. There are two Directory Server servers in Multi Master Replication and 14 WebGate servers that integrated with OAM. Is there a limitation number of WebGate for integrated to the OAM?
I have tried to set some parameters in OAM configuration to solve this problem. I set the Maximum Connection of Directory Server parameter to 10 value (in OAM Console), the LDAPOperationTimeout paramater to 1 hour value and the LDAPMaxNoOfRetries parameter to 2 value (in the globalparams.xml). After set these parameters, the error is not appear in some days, but suddenly appear again in the same error message. May be set these parameters is not appropriate solution for the problem or the value that I set is not correct. Any experience with this?
I still don't know what the root cause of this problem. Restart all of OAM services (including the WebGate) is temporary solution when the error appear.
Any idea for this problem?
Thanks in advice.

Hi Jun-Y,
Thank you for your answer.
What do you means with the Directory Server's idle timeout is the "Idle Timeout" parameter in LDAP Client Control Settings?
I use Oracle Directory Server Enterprise 11.1.1.5.0. Now, the Directory Server's idle timeout parameter is "unlimited" value.
If the idle timeout of the load balancer set 1 hour, it means that I must change the directory server's idle timeout to be less than 1 hour. Isn't right?

Hyper-V 2012 R2 roles, access denied, failed to connect to service, AzMan....

Hi All,
I have followed dozens of tutorials to set up roles for Hyper-V, but I keep coming up short. I have no problem managing the five domain-joined 2012 R2 Core Hyper-V servers we have remotely from my Windows 8.1 PC, but I have a lab box I would like to grant
specific permissions to some Help Desk users on.
The key tutorial I have followed is from John Howard (http://blogs.technet.com/b/jhoward/archive/2008/04/01/part-4-domain-joined-environment-hyper-v-remote-management-you-do-not-have-the-requested-permission-to-complete-this-task-contact-the-administrator-of-the-authorization-policy-for-the-computer-computername.aspx),
but it still does not allow a non-admin account to use Hyper-V Manager remotely. Without his tutorial, I get access denied with my "TestUser" account. After following his steps, Hyper-V Manager appears to connect to the server, but says "The
Virtual Machine Management service is not available." Even using his HVRemote with the /show flag, everything shows as PASSED.
Digging deeper, I see dozens of failed audit Event Viewer logs saying "TestUser" is requesting READ to Service Control Manager. That sent me searching, and I found
http://arnoutboer.nl/weblog/?p=300 and http://msdn.microsoft.com/en-us/library/windows/desktop/aa374928(v=vs.85).aspx.
After granting "AU" (Authenticated Users) every permission resembling "read", Hyper-V Manager now shows "There are no virtual machines to show" (or something along those lines); even though I know there are about 30 VMs on this
host. I try to create a new VM (out of curiosity, and now that those options actually appear), and I get permission denied immediately after the create VM wizard pops up.
Why is this such a convoluted process? I would appreciate any help creating Roles for Hyper-V 2012.
Thank you in advance!

Hi Eric (cool name BTW!)
Putting them in Hyper-V Administrators is definitely not an option.
I absolutely believe Microsoft would do something to push you into buying their software; just as we had to purchase Windows 8.1 Pro to remotely manage our 2012 R2 servers. However, as far as I am seeing, AzMan is still in 2012 R2. Whether it works or not
is another story, but AzMan.msc is still there and I can run it on any of our 2012 R2 GUI installs.
Actually just found this:
http://technet.microsoft.com/en-us/library/dn303411.aspx. According to that, it has not yet been removed, but it has been deprecated. From what I am seeing, the Hyper-V portion of it is definitely broken.
I will look into the remote endpoints solution you mentioned. Thank you for the suggestion. I just recently took the plunge into learning C++, so maybe a Hyper-V manager of sorts will be an app to
attempt to write, haha.
Eric Christensen

Direct Access 2012 -- Windows 8.1 -- ERROR_IPSEC_IKE_NO_POLICY

Hello Everyone,
hope someone can help out because i've tried all the troubleshhoting i could think of
i have a DA 2012 insfrastructure (Single NIC signle Server)
everything is working fine on my windows 7s but i can't seem to have my windows 8.1 to connect
i can ping all my DA ipv6 Adresses fro the client but the ipsec negociation is failing,
after lots of logging i managed to find this in the Firewall logs :
<error>ERROR_IPSEC_IKE_NO_POLICY</error>
<frequency>215</frequency>
so i understant the negociation is failing but no idea why :s
i though about the CRL but the windows 7 has the same certificate and is working fine...
any ideas ?
cheers
Hitch Bardawil

and the log
[9/8/2014 3:39:14 PM]: In worker thread, going to start the tests.
[9/8/2014 3:39:14 PM]: Running Network Interfaces tests.
[9/8/2014 3:39:14 PM]: Wi-Fi (Intel(R) Centrino(R) Advanced-N 6200 AGN): fe80::1026:d8f9:ded7:a2fb%3;: 192.168.1.124/255.255.255.0;
[9/8/2014 3:39:14 PM]: Default gateway found for Wi-Fi.
[9/8/2014 3:39:14 PM]: Teredo Tunneling Pseudo-Interface (Teredo Tunneling Pseudo-Interface): 2001:0:5ef5:79fb:65:2ac:92ff:d1b2;: fe80::65:2ac:92ff:d1b2%9;
[9/8/2014 3:39:14 PM]: No default gateway found for Teredo Tunneling Pseudo-Interface.
[9/8/2014 3:39:14 PM]: iphttpsinterface (iphttpsinterface): fddd:4cc:499:1000:b50f:a4fe:2c78:1299;: fddd:4cc:499:1000:6815:8f66:437e:ac7d;: fe80::b50f:a4fe:2c78:1299%10;
[9/8/2014 3:39:14 PM]: No default gateway found for iphttpsinterface.
[9/8/2014 3:39:14 PM]: Wi-Fi has configured the default gateway 192.168.1.1.
[9/8/2014 3:39:14 PM]: Default gateway 192.168.1.1 for Wi-Fi replies on ICMP Echo requests, RTT is 5 msec.
[9/8/2014 3:39:14 PM]: Received a response from the public DNS server (8.8.8.8), RTT is 55 msec.
[9/8/2014 3:39:14 PM]: The public DNS Server (2001:4860:4860::8888) does not reply on ICMP Echo requests, the request or response is maybe filtered?
[9/8/2014 3:39:14 PM]: Running Inside/Outside location tests.
[9/8/2014 3:39:14 PM]: NLS is https://nls.grsea.priv/.
[9/8/2014 3:39:14 PM]: NLS is not reachable via HTTPS, the client computer is not connected to the corporate network (external) or the NLS is offline.
[9/8/2014 3:39:14 PM]: NRPT contains 2 rules.
[9/8/2014 3:39:14 PM]: Found (unique) DNS server: fddd:4cc:499:3333::1
[9/8/2014 3:39:14 PM]: Send an ICMP message to check if the server is reachable.
[9/8/2014 3:39:14 PM]: DNS server fddd:4cc:499:3333::1 is online, RTT is 55 msec.
[9/8/2014 3:39:14 PM]: Running IP connectivity tests.
[9/8/2014 3:39:15 PM]: The 6to4 interface service state is default.
[9/8/2014 3:39:15 PM]: Teredo inferface status is online.
[9/8/2014 3:39:15 PM]: The configured DirectAccess Teredo server is win8.ipv6.microsoft.com..
[9/8/2014 3:39:15 PM]: The IPHTTPS interface is operational.
[9/8/2014 3:39:15 PM]: The IPHTTPS interface status is IPHTTPS interface active.
[9/8/2014 3:39:15 PM]: IPHTTPS is used as IPv6 transition technology.
[9/8/2014 3:39:15 PM]: The configured IPHTTPS URL is https://da2012.thelem-assurances.fr:443.
[9/8/2014 3:39:15 PM]: IPHTTPS has a single site configuration.
[9/8/2014 3:39:15 PM]: IPHTTPS URL endpoint is: https://da2012.thelem-assurances.fr:443.
[9/8/2014 3:39:15 PM]: Successfully connected to endpoint https://da2012.thelem-assurances.fr:443.
[9/8/2014 3:39:15 PM]: No response received from grsea.priv.
[9/8/2014 3:39:15 PM]: Running Windows Firewall tests.
[9/8/2014 3:39:15 PM]: The current profile of the Windows Firewall is Private.
[9/8/2014 3:39:15 PM]: The Windows Firewall is enabled in the current profile Private.
[9/8/2014 3:39:15 PM]: The outbound Windows Firewall rule Gestion réseau de base - Teredo (Trafic sortant UDP) is enabled.
[9/8/2014 3:39:15 PM]: The outbound Windows Firewall rule Réseau de base - IPHTTPS (TCP-Sortant) is enabled.
[9/8/2014 3:39:15 PM]: Running certificate tests.
[9/8/2014 3:39:15 PM]: Found 3 machine certificates on this client computer.
[9/8/2014 3:39:15 PM]: Checking certificate [no subject] with the serial number [21BDEAFA00000000123F].
[9/8/2014 3:39:15 PM]: The certificate [21BDEAFA00000000123F] contains the EKU Client Authentication.
[9/8/2014 3:39:15 PM]: The trust chain for the certificate [21BDEAFA00000000123F] was sucessfully verified.
[9/8/2014 3:39:15 PM]: Checking certificate [no subject] with the serial number [2292E531000000001240].
[9/8/2014 3:39:15 PM]: The certificate [2292E531000000001240] contains the EKU Client Authentication.
[9/8/2014 3:39:15 PM]: The trust chain for the certificate [2292E531000000001240] was sucessfully verified.
[9/8/2014 3:39:15 PM]: Checking certificate CN=SA000003B.grsea.priv with the serial number [1DD5B26600000000123D].
[9/8/2014 3:39:15 PM]: The certificate [1DD5B26600000000123D] contains the EKU Client Authentication.
[9/8/2014 3:39:15 PM]: The trust chain for the certificate [1DD5B26600000000123D] was sucessfully verified.
[9/8/2014 3:39:15 PM]: Running IPsec infrastructure tunnel tests.
[9/8/2014 3:39:15 PM]: Failed to connect to domain sysvol share \\grsea.priv\sysvol\grsea.priv\Policies.
[9/8/2014 3:39:15 PM]: Running IPsec intranet tunnel tests.
[9/8/2014 3:39:15 PM]: Successfully reached fddd:4cc:499:1000::1, RTT is 58 msec.
[9/8/2014 3:39:15 PM]: Successfully reached fddd:4cc:499:1000::2, RTT is 89 msec.
[9/8/2014 3:39:15 PM]: Failed to connect to HTTP probe at http://directaccess-WebProbeHost.grsea.priv.
[9/8/2014 3:39:15 PM]: Running selected post-checks script.
[9/8/2014 3:39:15 PM]: No post-checks script specified or the file does not exist.
[9/8/2014 3:39:15 PM]: Finished running post-checks script.
[9/8/2014 3:39:15 PM]: Finished running all tests.
Hitch Bardawil

Windows 8.1 laptop not connecting to domain in branch office

We have a problem with a laptop.
It is installed in our Head office (The Netherlands), just like all other laptops by using an image.
Tested and working on the domain.
The user had to go to one of our branch offices (China) and when he connected there, the laptop just won't connect to the domain.
When he plugged in the laptop, it keeps trying to connect it's directaccess.
Other laptops (same image) immediately recognize the domain network, but this laptop just won't.
I am able to ping everything on the local network (MPLS connection), from HQ to all Branch offices but not access them.
I've tried changing the DNS settings, but without any result.
Any suggestions?

Hi,
According to this tool's description, I think it should be helpful to check system current enviroment, such as network, certificates, etc. problem. Actually according to your description, I doubt it probably network enviroment of ISP problem, but we should
find a way to verify our suspect. Then this tool would be convenient, it also would generate a trace log and it would be helpful with troubleshooting.
The DirectAccess Client Troubleshooting Tool is a graphical application, based on the .NET Framework, which checks the health of a DirectAccess client by running various tests. Built-in health tests: The following tests are currently implemented:
Network interfaces Network location (NLS and NRPT DNS) IP connectivity (6to4, Teredo, IPHTTPS, entry point in a multisite setup, DNS) Windows Firewall (applied profile, Firewall outbound rules) Certificates (EKU Client Authentication, trust chain for AIA and
CRL) IPsec infrastructure tunnel (Domain SysVol share) IPsec intranet tunnel (PING and HTTP probes) Additional features Run post-check script (PowerShell, VBScript, BAT or CMD file)
Roger Lu
TechNet Community Support

Configuration of Direct Access 2012

Good morning.
I have tried to set up Direct Access from what I see is pretty much a 30-40 minute job, but has turned out to be something of a pain. Having followed the video on youtube for Windows Server 2012 with Basic PKI configuration and Windows 7 clients. I
have set up a working DA server with no issues and all green ticks.
Here's a run down.
I have a DC (2012) with the CA already installed.
I have a virtual DA (2012) set up with the advanced settings.
I have a a TMG 2010 server as the firewall with a Non-Web Publishing rule designed to forward HTTPS requests to the DA on the internal network.
The set up went as planned and I followed the instruction to set up the PKI and all computers have picked up a computer Certificate for the CA so that the internal root is validated.
The Certificates that I chose for the DA server were as follows;
DirectAccess-NLS.mydomain.local
remote.my-external-domain-name.co.uk
both published from my internal CA so that the root of the certificates were valid.
I have a Third party wildcard cert ( *.my-external-domain-name.co.uk ) for TMG to allow other connection such as VPN and web access.
DA Config:
Step 1: Remote Clients
I set up the DA server as per the video, set the DirectAccessClient group, and in the
Network Connectivity Assistant The resource was filled in with the
http://diectaccess-WebProbeHost URL.
Step 2: Remote Access Server
The Network Topology was set to Behind an edge device (with single network adapter), and then is says to type in the 'PUBLIC NAME' used by clients to connect to the Remove Access Server. Here I typed in the external DNS
name remote.my-external-domain-name.co.uk.
Network Adapters had the one ethernet and an IPv6 address. The
Select Certificate sued to authenticate IP-HTTPS connections has the CN=remote.my-external-domain-name.co.uk.
Authentication is set to AD and I used the root certificate of the CA for
use computer certificates. I also Enabled windows 7 client computers to connect via DirectAccess.
Step 3: Infrastructure Servers
Network Location Sevrer had the NLS is deployed on this server with the
DirectAccess-NLS cert.
DNS had the internal domain and the DirectAccess-NLS. the Internal domain was pointing to the IPv4 address of the DA. I read that I need to put the external name suffix of remote.my-external-domain-name.co.uk entry in and pointed that
to the internal DA IPv4 address also.
DNS Suffix List was set automatically and I also added my external domain name just in case.
Managerment was straight forward and I pointed to our System Centre 2012 R2 server.
Upon clicking finish and applying the GPO policies everything went according to plan. All green ticks. I did a GPupdate on the client I was testing and the GPO policies came through.
Now the issue I have is that on the internal network I get the Last Error 0x80190190 unable to connect to server. Now I am sure that this should say active as it is inside the network. I get the same error out side. When I check the DA server for
netsh int https sh int it returns the value that client authentication = NONE. I set it up to use computer certificates and even is I uncheck that it does not change.
It there a straight forward thing I missed or is it to do with publishing in TMG. Internally the direct access client will not connect as it will find the NLS in the internal DNS as I have the host record for both the server FQDN and the DirectAccess-NLS
potining to the IPv4 address. I also have the external remote.my-external-domain-name.co.uk entry in the internal DNS to point to the internal IPv4.
I have opened the ports for 443, 62000 on the DA for the IIS inbound and outbound.
I have a windows 8 client but need to test it as Windows 8 is supposed to work just like that.
What am I doing wrong here?? Any ideas would be much appreciated.

Thank you for this Jordan.
I have now got it working. The next step is to make sure my applications are all using Names rather than IP addresses.
I have basically setup the system as per my original thread that follows, NOT in BOLD.
I have tried to set up Direct Access from what I see is pretty much a 30-40 minute job, but has turned out to be something of a pain. Having followed the video on youtube for Windows Server 2012 with Basic PKI configuration and Windows 7 clients. I have
set up a working DA server with no issues and all green ticks.
Here's a run down.
I have a DC (2012) with the CA already installed.
I have a virtual DA (2012) set up with the advanced settings.
I have a a TMG 2010 server as the firewall with a Non-Web Publishing rule designed to forward HTTPS requests to the DA on the internal network.
The set up went as planned and I followed the instruction to set up the PKI and all computers have picked up a computer Certificate for the CA so that the internal root is validated.
The Certificates that I chose for the DA server were as follows;
DirectAccess-NLS.mydomain.local
remote.my-external-domain-name.co.uk
both published from my internal CA so that the root of the certificates were valid.
I have a Third party wildcard cert ( *.my-external-domain-name.co.uk ) for TMG to allow other connection such as VPN and web access.
DA Config:
Step
1: Remote Clients
I set up the DA server as per the video, set the DirectAccessClient group, and in the Network Connectivity Assistant The resource was
filled in with the http://diectaccess-WebProbeHost URL.
Step
2: Remote Access Server
The Network Topology was set to Behind
an edge device (with single network adapter), and then is says to type in the 'PUBLIC NAME' used by clients to connect to the Remove Access Server. Here I typed in the external DNS name remote.my-external-domain-name.co.uk.
Network Adapters had the one ethernet and an IPv6 address. The Select
Certificate sued to authenticate IP-HTTPS connections has the CN=remote.my-external-domain-name.co.uk.
Authentication is set to AD and I used the root certificate of the CA for use
computer certificates. I also Enabled windows 7 client computers to connect via DirectAccess.
Step
3: Infrastructure Servers
Network Location Sevrer had the NLS
is deployed on this server with the DirectAccess-NLS cert.
DNS had the internal domain and the DirectAccess-NLS. the Internal domain was pointing to the IPv4 address of the DA. I read that I need
to put the external name suffix of remote.my-external-domain-name.co.uk entry in and pointed that to the internal DA IPv4 address also.
DNS Suffix List was set automatically and I also added my external domain name just in case.
Managerment was straight forward and I pointed to our System Centre 2012 R2 server.
Upon clicking finish and applying the GPO policies everything went according to plan. All green ticks. I did a GPupdate on the client I was testing and the GPO policies came through.
I have set up TMG as per the isa.org forum
http://www.isaserver.org/articles-tutorials/general/implementing-windows-server-2012-directaccess-behind-forefront-tmg-part2.html .
@ Jordan - I ensured that I had a separate external IP address for the requests from the clients to TMG as I publish websites internally.
I used a third party wildcard cert for the IP-HTTPS connect part in DA Config Step 2.
All the rest of the DA set up was pretty much out of the box as stated above.

I have CS 6 which requests I sign in to access my serial numbers, which I have already, and it fails to connect so that I cannot use the programs. How do I get past this, is there a direct line to customer support?

I have CS 6 which requests I sign in to access my serial numbers, which I have already, and it fails to connect so that I cannot use the programs. How do I get past this, is there a direct line to customer support in the UK?
Thanks

Sign in, activation, or connection errors | CS5.5 and later
Mylenium

Cannot connect to RDP farm through Direct Access

Hey everyone, hope you can help/
I have an issue connecting to the RD Farm when connected through Direct Access. I have tried specifying the RD Gateway to no avail. Cannot ping RD farm or session hosts through v4 but can v6. The address comes back as the 6to4 address and is different for
each ping to each session host.
When trying to RDP to the farm (or directly to a SH) certificate trust comes up so confirm that i am happy to trust the certificate for the connection, and it goes through to the point of initiating remote connection and then fails with the standard "Remote
Desktop cant connect to the remote computer..." message.
I am not entirely sure where or how to troubleshoot this first. Users local side of the wan are ok, its only external.
Apparently after numerous attempts the connection works but I am yet to witness this.

Russel,
the problem has been solved now! The final thing missing was just a check in a checkbox.
Below a comprehensive explanation that may help others.
We basically did what you proposed:
We sent a ping from one of the DA-Clients to the TS-Farm members. Since we got replies, we knew that IPv6 communication generally is okay. The answer received was an IPv6. In this scenario we had not yet given any IPv6 to the farm-members! Thus we knew it must
be comming from the DA DNS-Proxy. There are a number of DA-GPOs and one of them is dictating the net portion of the IPv6 to be used in DA-communication, appended by a hex-translation of the target computers IPv4. Therefore the DA DNS-Proxy is taking the GPO-set
IPv6-value, adds the IPv4 in hex and sends it back as an ICMP echo.
With this in place and working correctly one can ping any domain host from any DA-Client. This is configured when initially setting up DA and is handled by the wizzard. Once DA is installed this should all be in place without extra user interaction.
We then took those IPv6 answeres and turned them into fixed IPv6es of the farm-members (each member its own IPv6). So far so good, but this is where it still did not work. Evaluation of the Connection Broker log showed that the redirect reply still included
only the IPv4 of the target farm-member. With that (after a short while) we realized that one has to set a
check in the Connection Brokers Settings, so that the IPv6 LAN-Connection will be used for redirects as well and not only the IPv4 LAN-connection..... How stupid is that? :-)
But as we all know - in dealing with server configuration - you should always "know before you go". But even though you may think you do, when finally arriving you know you didn't.... And that's what we call experinece.
Thanks to Russel for your interest and help.
Brgds Ralf

ConfigMgr Clients connection over direct access.

My test client machine is running Windows 8.1 and connecting to network through Direct Access. I am running SCCM 2012 R2 on Windows Server 2012.
Test Machine: NYWIN8
SCCM Server: SCCM01
Domain: demo.local
I would like to understand how configmgr handles clients connecting through direct access. What all functionality is available for such clients?
On my client machine is see following errors:
FSPSTATEMESSAGE.LOG
Failed in WinHttpSendRequest API, ErrorCode = 0x2ee7
[CCMHTTP] ERROR: URL=HTTP://SCCM01.demo.local/SMS_FSP/.sms_fsp, Port=80, Options=480, Code=12007, Text=ERROR_WINHTTP_NAME_NOT_RESOLVED
POLICYAGENT.LOG
Policy
http://SCCM01.demo.local/SMS_MP/.sms_pol?WRC10000.SHA256:BE60C5A54E508758261E6EDAE80AB21576A214309B9E1E19EE1D5A96C4508EC4 is not available.
DATATRANSFERSERVICE.LOG
DTS job {E6FAADEE-F22E-4E89-92EE-C2D9C10C3056} BITS job {9C444FAB-FD3C-4A6B-B8A4-81DA159E4E45} failed to download source file
http://SCCM01.demo.local:80/SMS_MP/.sms_pol?WRC10000.SHA256:BE60C5A54E508758261E6EDAE80AB21576A214309B9E1E19EE1D5A96C4508EC4 to destination C:\Windows\CCM\Temp\{C9AA0DDC-BD37-442D-A00E-EE7404D47C12}.tmp with error 0x80190194
DTS job {E6FAADEE-F22E-4E89-92EE-C2D9C10C3056} BITS job {9C444FAB-FD3C-4A6B-B8A4-81DA159E4E45} partially completed 0/1 with error 0x80190194 context 5
Software Catalog Update Endpoint
Failed to open portal registry key 'Software\Policies\Microsoft\CCM'. maybe haven't been created yet. Error 0x80070002
WEDMTRACE.LOG
No CCM Identification blob
CAS.LOG
The number of discovered DPs(including Branch DP and Multicast) is 0
SMSCLIUI.LOG
Failed to set DNSSuffix value to the registry.
Are there any issues due to connecting using direct access?

When I try to deploy any software (7-ZIP or Notepad++) to this client I get following error:
The software change returned error code 0x87D00607(-2016410105).
I can deploy same software fine to other machines connecting on LAN.
Server Logs:
Portlctl
PORTALWEB's previous status was 0 (0 = Online, 1 = Failed, 4 = Undefined)
PORTALWEBs http check returned hr=0, bFailed=0
awbsctl
AWEBSVCs http check returned hr=0, bFailed=0
AWEBSVC's previous status was 0 (0 = Online, 1 = Failed, 4 = Undefined)
Client Logs:
CAS
The number of discovered DPs(including Branch DP and Multicast) is 0
CCMEVAL
Client's current MP is http://SCCM01.DEMO.local and is accessible
ClientLocation
Current AD forest name is Demo.local, domain name is Demo.local
Domain joined client is in Intranet
Rotating assigned management point, new management point [1] is: SCCM01.demo.local (7958) with capabilities: <Capabilities SchemaVersion="1.0"><Property Name="SSLState" Value="0"/></Capabilities>
Assigned MP changed from <SCCM01.demo.local> to <SCCM01.demo.local>.
ContentTransferManager
No data since 11/13/2013
CTM job {F6085C09-4C39-489E-A6F6-2C268398B7F2} successfully processed download completion.
DataTransfer
DTS job {B227AB6E-6D0F-4709-B8C6-AA8B66CBBE2D} BITS job {AE61D01C-E251-45FA-8B2C-2E22DDD91016} failed to download source file
http://SCCM01.demo.local:80/SMS_MP/.sms_pol?WRC10000.SHA256:BE60C5A54E508758261E6EDAE80AB21576A214309B9E1E19EE1D5A96C4508EC4 to destination C:\Windows\CCM\Temp\{22619283-47B1-445A-9262-C1FA54AD0F64}.tmp with error 0x80190194
DTS job {B227AB6E-6D0F-4709-B8C6-AA8B66CBBE2D} BITS job {AE61D01C-E251-45FA-8B2C-2E22DDD91016} partially completed 0/1 with error 0x80190194 context 5
Filebits
BranchCache Is Not Enabled
Failed to check PeerDistribution status. NOT able to do branch cache.
FSPSTATEMESSAGE
Failed in WinHttpSendRequest API, ErrorCode = 0x2ee7
[CCMHTTP] ERROR: URL=HTTP://SCCM01.demo.local/SMS_FSP/.sms_fsp, Port=80, Options=480, Code=12007, Text=ERROR_WINHTTP_NAME_NOT_RESOLVED
Successfully sent location services HTTP failure message.
InternetProxy
Failed to get proxy for url 'HTTP://SCCM01.demo.local/SMS_FSP/.sms_fsp'. Error 0x87d00215
InventoryAgent
Inventory: 9 Collection Task(s) failed.
SCCLIENT
Event maps to notification type = Application Enforcement Failed (Microsoft.SoftwareCenter.Client.Data.WmiConnectionManager at EventWatcher_EventArrived)
SMSCLIUI
Failed to set DNSSuffix value to the registry.
IPCONFIG /ALL from CLIENT:
Windows IP Configuration
   Host Name . . . . . . . . . . . . : NYWIN8
   Primary Dns Suffix . . . . . . . : demo.local
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : demo.local
   System Quarantine State . . . . . : Not Restricted
Ethernet adapter vEthernet (Internal):
   Connection-specific DNS Suffix . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #3
   Physical Address. . . . . . . . . : 00-15-5D-01-0B-07
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::d3f:4e51:c648:7b26%26(Preferred)
   Autoconfiguration IPv4 Address. . : 169.254.123.38(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 872420701
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-19-EA-A9-CE-E0-DB-55-D2-5E-59
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS over Tcpip. . . . . . . . : Enabled
Ethernet adapter vEthernet (External):
   Connection-specific DNS Suffix . : home
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2
   Physical Address. . . . . . . . . : 84-A6-C8-AF-03-DE
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::9cb5:5132:1f47:e7c6%24(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.1.5(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Thursday, January 2, 2014 1:27:53 PM
   Lease Expires . . . . . . . . . . : Saturday, January 4, 2014 12:27:55 PM
   Default Gateway . . . . . . . . . : 192.168.1.1
   DHCP Server . . . . . . . . . . . : 192.168.1.1
   DHCPv6 IAID . . . . . . . . . . . : 730113736
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-19-EA-A9-CE-E0-DB-55-D2-5E-59
   DNS Servers . . . . . . . . . . . : 192.168.1.1
   NetBIOS over Tcpip. . . . . . . . : Enabled
Wireless LAN adapter Local Area Connection* 3:
   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix . :
   Description . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter
   Physical Address. . . . . . . . . : 84-A6-C8-AF-03-DF
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
Ethernet adapter Bluetooth Network Connection:
   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix . :
   Description . . . . . . . . . . . : Bluetooth Device (Personal Area Network)
   Physical Address. . . . . . . . . : 84-A6-C8-AF-03-E2
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
Ethernet adapter Ethernet:
   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix . : home
   Description . . . . . . . . . . . : Realtek PCIe FE Family Controller
   Physical Address. . . . . . . . . : E0-DB-55-D2-5E-59
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
Tunnel adapter isatap.home:
   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix . : home
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
Tunnel adapter iphttpsinterface:
   Connection-specific DNS Suffix . :
   Description . . . . . . . . . . . : iphttpsinterface
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : fd64:fc00:d17b:1000:e1a7:9cc8:c3c7:d819(Preferred)
   Temporary IPv6 Address. . . . . . : fd64:fc00:d17b:1000:c598:7f17:e286:369d(Preferred)
   Link-local IPv6 Address . . . . . : fe80::e1a7:9cc8:c3c7:d819%10(Preferred)
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 369098752
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-19-EA-A9-CE-E0-DB-55-D2-5E-59
   NetBIOS over Tcpip. . . . . . . . : Disabled
Tunnel adapter isatap.{DC7D2C63-1506-49EC-A40F-AA4E56DE4001}:
   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix . :
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter #3
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Direct Access for Non Domain Machines

Hi,
In My IT-infra, there is multiple machines that is out my Office network & Domain..
Can we join these machines in domain via Direct Access implementation ? or for implementing Direct Access we required to join those non domain & out of office network machine to Domain first ?
secondly, can we implement the Direct access without any public certificate purchase, and without any IPV6 configuring in internal network,machines and in servers .currently i am using IPv4 IP on all Machines & Servers.
I have gone through the Direct Access Technet guide but i feel very complex document there ...can you please brief me about direct access implementation in simpale way, i want to implement direct access to join the internet based client machines to
domain and manage via/for SCCM ...
Shailendra Dev

Correct, DirectAccess clients must be domain joined. Also, only Windows 7 Ultimate, Windows 7 Enterprise, or Windows 8 Enterprise clients are able to be DirectAccess connected, so that may also make a difference to your situation. I see many customers deploy
DirectAccess for those Win7/Win8 domain-joined systems, and then make use of the traditional (RRAS) VPN on the same DirectAccess server for connecting any other operating systems or non-domain-joined machines. Those would just have to launch a manual VPN connection,
where the DirectAccess connections are of course automatically connected.
You don't "have" to use an SSL certificate that you purchased from a public CA, but you really should. It is definitely a best practice to use a trusted public certificate on your DirectAccess server. Further, if you have Windows 8 client computers,
you don't even need to distribute the machine certificates inside your network, but it is also a best practice that you do this anyway, to strengthen the authentication process.
No, you do not need IPv6 inside your network at all for DirectAccess to work.
Sounds like you might be interested in some additional reading on DA, here are the two books available on the subject:
https://www.packtpub.com/virtualization-and-cloud/microsoft-directaccess-best-practices-and-troubleshooting
https://www.packtpub.com/networking-and-servers/windows-server-2012-unified-remote-access-planning-and-deployment

Hyper-V Remote Admin on a Domain - Failed to connect to root\cimv2

I'm trying to configure our Hyper-V server so that a user on our domain has administrative control. Our Hyper-V server is on the domain running 2008 R2 (named SERVER85 below), and the client is on Win 7 Ent x64 (named DEV03 below, username accuraty\jkessel).
In the output below you can see that it appears we might have a problem with this user's access to the WMI path root\CIMv2, but if I pull up the advanced security settings for that node in WMI, I see:
Name: Justin Kessel ([email protected])
Apply to: This namespace and subnamespaces
Permissions allowed: "Enable Account" and "Remote Enable" (no others, no denies).
IMHO, the server, the desktop, and user are all fairly "vanilla" with nothing unusual going on. Maybe one thing worth noting: our Small Business Server 2008 (i.e. domain controller) is running as a VPS on SERVER85, so SERVER85 never boots with the
domain controller on. This hasn't ever caused problems except that the machine always thinks it's firewall should be in the "work" configuration instead of the "domain" configuration. I tested running the HVRemote script while the SERVER85 firewall
was turned off, and I get exactly the same results below.
One more note: this user currently can logon through RDP to SERVER85 and administer Hyper-V just fine. This user is *not* a domain admin or an admin on that server - I've simply provided him with the right permissions to be able to RDP and admin Hyper-V
only.
We used HVRemote and it output this info when run on the client:
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.
Hyper-V Remote Management Configuration & Checkup Utility
John Howard, Hyper-V Team, Microsoft Corporation.
http://blogs.technet.com/jhoward
Version 0.7 7th August 2009
INFO: Computername is DEV03
INFO: Computer is in domain accuraty.local
INFO: Current user is ACCURATY\JKessel
INFO: Assuming /mode:client as the Hyper-V role is not installed
INFO: Build 7600.16617.amd64fre.win7_gdr.100618-1621
INFO: Detected Windows 7/Windows Server 2008 R2 OS
INFO: Remote Server Administration Tools are installed
INFO: Hyper-V Tools Windows feature is enabled
DACL for COM Security Access Permissions
\Everyone    (S-1-1-0)
     Allow: LocalLaunch RemoteLaunch (7)
NT AUTHORITY\ANONYMOUS LOGON    (S-1-5-7)
     Allow: LocalLaunch (3)
BUILTIN\Distributed COM Users    (S-1-5-32-562)
     Allow: LocalLaunch RemoteLaunch (7)
BUILTIN\Performance Log Users    (S-1-5-32-559)
     Allow: LocalLaunch RemoteLaunch (7)
ANONYMOUS LOGON Machine DCOM Access
ANONYMOUS LOGON does not have remote access
This setting should only be enabled if required as security on this
machine will be lowered. This computer is in a domain. It is not
required if the server(s) being managed are in the same or trusted
domains.
Use hvremote /mode:client /anondcom:enable to turn on
Firewall Settings for Hyper-V Management Clients
Domain Firewall Profile is active
   Enabled: Hyper-V Management Clients - WMI (Async-In)
   Enabled: Hyper-V Management Clients - WMI (TCP-Out)
   Enabled: Hyper-V Management Clients - WMI (TCP-In)
   Enabled: Hyper-V Management Clients - WMI (DCOM-In)
Windows Firewall exception rule(s) for mmc.exe
Domain Firewall Profile is active
   Enabled: Microsoft Management Console (UDP)
   Enabled: Microsoft Management Console (TCP)
Additional configuration may be necessary
This computer is in a domain. If the target server is in a workgroup,
you may need to set credentials for the server for Hyper-V Remote
Management to operate correctly. This step should not be necssary if
the target server is in the same or trusted domain as this computer.
If necessary, from a *NON* elevated command prompt, enter:
     cmdkey /add:ServerComputerName /user:ServerComputerName\UserName /pass
Note that you MUST enter ServerComputerName to BOTH parameters.
You will be prompted for a password after entering the command.
IP Configuration
Windows IP Configuration
   Host Name . . . . . . . . . . . . : DEV03
   Primary Dns Suffix . . . . . . . : accuraty.local
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : accuraty.local
Ethernet adapter Local Area Connection:
   Connection-specific DNS Suffix . : accuraty.local
   Description . . . . . . . . . . . : Intel(R) PRO/100 VE Network Connection
   Physical Address. . . . . . . . . : 00-19-D1-05-57-01
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::4406:b48c:dea3:de50%11(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.16.48.185(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Wednesday, November 10, 2010 3:19:23 AM
   Lease Expires . . . . . . . . . . : Monday, December 20, 2010 9:39:25 AM
   Default Gateway . . . . . . . . . : 172.16.48.1
   DHCP Server . . . . . . . . . . . : 172.16.48.210
   DHCPv6 IAID . . . . . . . . . . . : 234887633
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-13-62-35-81-00-19-D1-05-57-01
   DNS Servers . . . . . . . . . . . : 172.16.48.210
66.209.192.5
8.8.8.8
                                       66.209.192.15
8.8.4.4
4.2.2.1
   NetBIOS over Tcpip. . . . . . . . : Enabled
Tunnel adapter isatap.accuraty.local:
   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix . :
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
Tunnel adapter Teredo Tunneling Pseudo-Interface:
   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix . :
   Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
Stored Credentials
Currently stored credentials:
    Target: WindowsLive:[email protected]
    Type: Generic
    User:
[email protected]
    Local machine persistence
    Target: LegacyGeneric:target=WindowsLive:(token):[email protected];serviceuri=contacts.msn.com
    Type: Generic
    User:
[email protected]
    Local machine persistence
    Target: Domain:target=TERMSRV/server85
    Type: Domain Password
    User: ACCURATY\jkessel
    Local machine persistence
    Target: WindowsLive:target=virtualapp/didlogical
    Type: Generic
    User: 02mybhosqazs
    Local machine persistence
Testing connectivity to server:server85
1: - nslookup for DNS verification.
     Note that failure is OK if you don't have a DNS infrastructure
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
Server: sbs01.accuraty.local
Address: 172.16.48.210
Name:    server85.accuraty.local
Address: 172.16.48.201
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
2: - ping attempt (ping -4 -n -1 server85)
   Note the ping may timeout - that is OK. However, if you get an
     error that server85 could not be found, you need to fix DNS
     or add an entry to the hosts file. Test 3 will fail and provide more
     guidance.
     This may take a second or two...
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
Pinging server85.accuraty.local [172.16.48.201] with 32 bytes of data:
Reply from 172.16.48.201: bytes=32 time<1ms TTL=128
Ping statistics for 172.16.48.201:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
3: - Connect to root\cimv2 WMI namespace
***** Failed to connect to root\cimv2
***** Error:     -2147024891 Access is denied.
***** Namespace: root\cimv2
     FAIL - Was unable to connect. Diagnosis steps:
     - Have you run hvremote /add:user or hvremote /add:domain\user
       on server85 to grant access?
     - Are you sure the server name 'server85' is correct?
     - Did you use cmdkey if needed? More information higher up.
     - Did you restart server85 after running hvremote /add for
       the very first time? (Subsequent adds, no restart needed.)
     - Is DNS operating correctly and was server85 found?
       Look at the output of tests 1 and 2 above to verify that the
       IPv4 address matches the output of 'ipconfig /all' when run on
       server85. If you do not have a DNS infrastructure,
       edit \windows\system32\drivers\etc on DEV03
       to add an entry for server85.
INFO: Are running the latest version
3 warning(s) or error(s) were found in the configuration. Review the
detailed output above to determine whether you need to take further action.
Summary is below.
1: Anonymous Logon does not have remote access (may be ok)
2: You *may* need to set credentials for access to the server
3: Cannot connect to root\cimv2 on server85
I'd greatly appreciate some help!
Thanks!

Hi,
It seems that you were using Hyper-V Remote Management Configuration Utility from the link
http://code.msdn.microsoft.com/HVRemote, if so, you can refer to the following link.
Configure Hyper-V Remote Management in seconds
http://blogs.technet.com/jhoward/archive/2008/11/14/configure-hyper-v-remote-management-in-seconds.aspx
By the way, if you want to perform the further research about Hyper-V Remote Management Configuration Utility, it is recommend that you to get further
support in the corresponding community so that you can get the most qualified pool of respondents. Thanks for your understanding.
For your convenience, I have list the related link as followed.
Discussions for Hyper-V Remote Management Configuration Utility
http://code.msdn.microsoft.com/HVRemote/Thread/List.aspx
Best Regards,
Vincent Hu

Cannot view history of direct access users connecting to Forefront UAG

Hi, I'm trying to get a list of the users that have been connecting through UAG Direct Access for the past month. I've tried using the methods shown in the technet articles about monitoring of UAG Direct Access either using Powershell or the TMG event loggin
console, using this links:
http://technet.microsoft.com/en-us/library/gg313776.aspx
http://technet.microsoft.com/en-us/library/gg313783.aspx
Using the TMG event logging I see a lot of data from a few days back, even if the filter is set to 30 days, and the log is supposed to be up to 8GB in size before overwriting. The info that it shows is only about sessions to the portal trunk and not direct
access. I know this because on the UAGModuleID column there is no there are no "connected" or "managed" sessions, all are SessionMgr, UserMgr, Filter and RDG mainly.
Through powershell I tried running the following commands after importing the module according to the article:
Get-Directaccessusers -showhistory $true and no results are shown.
Get-Directaccessusers -showhistory $true -starttime "1/6/2015 8:00AM" and no results shown
Get-Directaccessusers -showhistory $true -starttime "1/6/2015" no results
Get-Directaccessusers -showhistory $true -starttime "1/2/2015 8:00AM" -Endtime "1/11/2015 8:00PM" no results
Get-Directaccessusers -showhistory $true -username user = no results.
Get-Directaccessusers -username user = no results
the only command that shows any data is just Get-Directaccessusers but that shows the current Direct Access users, no history.
I checked the Registry HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\e-Gap\von\MonitorMgr\sql-builtin-log registry key and it is on 1.
Any ideas on how can I get more history data on the direct access users connecting through UAG?
Please let me know.
Appreciated it.
Thank you!
Eduardo Rojas

Russel,
the problem has been solved now! The final thing missing was just a check in a checkbox.
Below a comprehensive explanation that may help others.
We basically did what you proposed:
We sent a ping from one of the DA-Clients to the TS-Farm members. Since we got replies, we knew that IPv6 communication generally is okay. The answer received was an IPv6. In this scenario we had not yet given any IPv6 to the farm-members! Thus we knew it must
be comming from the DA DNS-Proxy. There are a number of DA-GPOs and one of them is dictating the net portion of the IPv6 to be used in DA-communication, appended by a hex-translation of the target computers IPv4. Therefore the DA DNS-Proxy is taking the GPO-set
IPv6-value, adds the IPv4 in hex and sends it back as an ICMP echo.
With this in place and working correctly one can ping any domain host from any DA-Client. This is configured when initially setting up DA and is handled by the wizzard. Once DA is installed this should all be in place without extra user interaction.
We then took those IPv6 answeres and turned them into fixed IPv6es of the farm-members (each member its own IPv6). So far so good, but this is where it still did not work. Evaluation of the Connection Broker log showed that the redirect reply still included
only the IPv4 of the target farm-member. With that (after a short while) we realized that one has to set a
check in the Connection Brokers Settings, so that the IPv6 LAN-Connection will be used for redirects as well and not only the IPv4 LAN-connection..... How stupid is that? :-)
But as we all know - in dealing with server configuration - you should always "know before you go". But even though you may think you do, when finally arriving you know you didn't.... And that's what we call experinece.
Thanks to Russel for your interest and help.
Brgds Ralf

Direct access network connectivity assistant, the update is not applicable

Been testing DirectAccess for a couple of weeks now, and all seemes to be working fine. But now it want to install the DA connectivity assistant but it fails to install. When searching for updates on this computer it gives an error message as seen in the
screenshot below .
I've reinstalled Windows , updated windows, removed the virus scanner, checked if the update was already installed. Nothing worked
OS = Windows 7 Enterprise N
Windows update log appears
2013-11-15 09:54:11:265
912 1290
Report CWERReporter finishing event handling. (00000000)
2013-11-15 09:54:42:534
912 1290
Report CWERReporter finishing event handling. (00000000)
2013-11-15 09:54:56:188
4736 984
COMAPI ----------- COMAPI: IUpdateServiceManager::RemoveService -----------
2013-11-15 09:54:56:188
4736 984
COMAPI - ServiceId = {f8fc7b4b-f693-4113-ab5f-137e03025faa}
2013-11-15 09:54:56:609
4736 984
COMAPI ISusInternal::DisconnectCall failed, hr=8024000C
2013-11-15 09:54:56:625
4736 984
COMAPI waiting for worker thread to complete
2013-11-15 09:54:56:625
4736 984
COMAPI Removed OnCompleted callback from GIT (cookie=256)
2013-11-15 09:54:56:625
4736 984
COMAPI IUpdateService removing volatile scan package service, serviceID = {F8FC7B4B-F693-4113-AB5F-137E03025FAA}
2013-11-15 09:54:56:641
912 1334
Agent WARNING: WU client fails CClientCallRecorder::RemoveService with error 0x80248014
2013-11-15 09:54:56:656
4736 984
COMAPI WARNING: ISusInternal::RemoveService failed, hr=80248014

Hi,
Firstly, I would like to confirm with you if it worked before on Windows 7 Enterprise N version.
As I known, following are some additional features that Windows 7 Enterprise N edition has and other versions does not have:
a. Direct Access
b. Branch cache
c. Federated search
You need to meet the following requirements to install the DA connectivity assistant.
Windows 7 Enterprise, Windows 7 Ultimate
1. 10 MB of disk space.
2. 10 MB of RAM.
3. Microsoft Word or Microsoft Word Viewer (available as a free download) can be used to view Word documents.
I would like to suggest you download and install it from official website.
Microsoft DirectAccess Connectivity Assistant 2.0
http://www.microsoft.com/en-us/download/details.aspx?id=29039
Hope it helps.
Regards,
Blair Deng
Blair Deng
TechNet Community Support

Direct Access: domain.LOCAL supported?

Hi,
Our domain was configured using company.local. I am now trying to deploy Direct Access on a Windows Server 2012 R2 server using a single NIC deployment.
Do we have to change our domain name to company.com in order to deploy Direct Access? If not - are there any special considerations when deploying using the .local domain?
We have a forward lookup zone for domain.com in addition to the domain.local on our DNS servers. We intend to use "da.domain.com" as the "public name used by clients to connect to the Remote Access server".

Hi,
You do not have to change.
With a single NIC, I suppose your server is behind a NAT device.
For your reference:
Step-By-Step: Enabling DirectAccess in Windows Server 2012 R2
http://blogs.technet.com/b/canitpro/archive/2014/01/06/step-by-step-enabling-directaccess-in-windows-server-2012.aspx
STEP 6: Test DirectAccess Client Connectivity from Behind a NAT Device
http://technet.microsoft.com/en-us/library/hh831524.aspx
Hope this helps.

Direct Access Troubleshooting: Failed to connect to domain sysvol share

Similar Messages

Maybe you are looking for