TechOnTip Weblog

Run book for Technocrats

Archive for March, 2013

Windows 7 Direct Access Client Troubleshooting Commands

Posted by Brajesh Panda on March 13, 2013

Click here for other Direct Access related articles.

Windows 7

  1. Check IPv6 enabled Interfaces

Netsh interface ipv6 show interface

  1. Determine if Direct Access client is inside or outside of network

Netsh dnsclient show state


  1. Verify Name Resolution Policy Table

Netsh namespace show policy
(same output while in Corporate or Outside Network)

Netsh namespace show effectivepolicy

  • Shows active policy while outside network & output is same as above command
  • While client is intranet it will give below message because no active policies are there

    DNS Effective Name Resolution Policy Table Settings

    Note: DirectAccess settings would be turned off when computer is inside corporate network

  1. Check current Windows Firewall Profile

Netsh advfirewall monitor show currentprofile

  1. Check Direct Access connection security rules thru Windows Firewall Advance Security Settings

Wf.msc

  1. Check current Windows Security Associations (while successfully connected to Direct Access).
    1. Windows Firewall Advance Security Main Mode or use use “netsh advfirewall monitor show mmsa

  1. Windows Firewall Advance Security Quick Mode or use use “netsh advfirewall monitor show qmsa”

  1. Generate Troubleshooting Logs if Direct Access is not connecting

Right Click Direct Access Connectivity Assistant & click Advance Diagnostics

8. Check NSLOOKUP for corporate network

nslookup -q=aaaa <fqdn intranet resource> <ipv6 DNS server>

Note: IPv6 DNS server is the IPv6 Address you got from “netsh namespace show effectivepolicy”

Advertisements

Posted in Direct Access, Windows 2012 | 3 Comments »

Windows 2012 Direct Access – Windows 7 Client Testing

Posted by Brajesh Panda on March 10, 2013

Click here for other Direct Access related articles.

In last article I have discussed how to test Windows 8 Direct Access Clients with and without computer certificate. In this article let’s test a Win 7 computer. To read other Windows 2012 Direct Access articles visit Direct Access tab on the home page of the blog.

  • Install Windows 7 Enterprise or Ultimate version of client Computer
  • Join it Contoso. Local Domain
  • Add the Computer Account to “Contoso\DirectAccessClients-Win7” security group
  • As Computer certificate is necessary for Windows 7 “Contoso\DirectAccessClients-Win7” group has been configured for auto enrollment of computer certificates
  • Make sure computer certificate is installed in Windows 7 Client Certificate store
  • Enable Windows 7 Access in Remote Access Server Management Console

  • Make sure GPO is applied to the computer. To validate run “Gpresult /r” and make sure direct access client policy is applied under computer configuration
  • Move the computer to public internet and disconnect from corporate network. Check IPConfig & make sure it got IP-HTTPS IP address
  • Try to ping tunnel end points & direct access server IPv6 Address
  • Try to ping Contoso. Local & other internal corporate servers
  • Try to access RDP & \\UNC path for internal resources
  • Check advance firewall console for created tunnels “wf.msc”
  • Check corporate DNS server for dynamic registration of IP-HTTPS interface IP address for Win 7 client.
  • However in Windows 7 there is NO inbuilt Network Connectivity Assistant
    to troubleshoot or disconnect or use local name resolution. So we have to install Direct Access Connectivity 2.0
    tool & configure related settings as per DCA 2.0 guide.
  • Download Direct Access Connectivity Assistant 2.0 Package to Windows 7 client & extract. Package contains below files

  • As per OS version (x64/x86) install respective MSI file. Installer will download Windows Update KB2666914
    from internet and install on the Windows 7 machine. Need internet connection.
  • After DCA 2.0 installation, Existing Network Connectivity Assistant GPO settings will not get applied to it & it will still give error saying Corporate Connectivity is not working. Even inside the corporate network it will throw the same error. If we generate diagnostic logs it will say it is not configured correctly.
  • So Copy GPO ADML & ADMX files as per below in the machine where you configure GPO – may be a domain controller or same DA Server.
    • Copy the DirectAccess_Connectivity_Assistant_2_0_ GP.admx file to the folder %systemroot%\PolicyDefinitions.
    • Copy the DirectAccess_Connectivity_Assistant_2_0_ GP.adml file to the folder %systemroot%\PolicyDefinitions\language. For example, for US English, copy the file to %systemroot%\PolicyDefinitions\en-us.
  • Open Group Policy Management Console & copy respective settings from DirectAccess Client Experience Settings
    to DirectAccess Connectivity Assistant. In below picture from Green to Red.

  • Connect the Win 7 client to corporate network & Gpupdate. After Gpupdate you should able to see DCA is working fine.

  • Reconnect the Win 7 client to Internet & make sure client is getting IPV6 address on IP-HTTPS interface & Direct Access connection is working fine.
  • As you updated the GPO, make sure you Gpupdate the Windows 8 clients too

Posted in Direct Access, Windows 2012 | 9 Comments »

Windows 2012 Direct Access – Windows 8 Client Testing

Posted by Brajesh Panda on March 10, 2013

Click here for other Direct Access related articles.

In last two articles I have demonstrated how to Install, Configure & Verify Direct Access installation. In this article we will test & verify using a Windows 8 Client. For Windows 7 clients check out my next article. Visit Direct Access
tab on the home page for other Windows 2012 Direct Access articles.

  • Install Windows 8 Enterprise Client Computer
  • Join it Contoso. Local Domain
  • Check certificate store to ensure no computer certificate is installed in this machine
    • Note: Remember certificate is not mandatory and we have not selected to use computer certificate in configuration section. We will test with certificate later in this article
  • Add the Computer Account to “Contoso\DirectAccessClients-Win8” security group
  • Make sure GPO is applied to the computer. To validate run “Gpresult /r” and make sure direct access client policy is applied under computer configuration
  • You will able to see Direct Access Connection in the Network List
    • On Windows Start bar click on the network Icon
    • You should able to see “Contoso DA Connection
  • Make sure Windows Firewall is NOT stopped
  • Check windows firewall advance setting rules – “wf.msc

  • Open properties of “DirectAccessPolicy-ClientToCorpSimplified” policy & from Authentication tab check authentication method.

  • Let’s disconnect the computer from Contoso.Local LAN network & start the external wireless connection and observe what is happening
  • Observe network connection list; you will Contoso DA Connection is connected

  • In Advance Windows firewall console and check out Main Mode Security Associations or tunnels. You can observe 1st Computer Account is used & User Account for authentication.

  • Check out IPConfig details in Windows 8 computer. You will find both IP-HTTPS and Teredo interfaces has been assigned IPv6 addresses.
  • Just note if IP-HTTPS interface has an IP address, it means system is using IP-HTTPS technology. DA Client by default tries Teredo connection 1st with its auto address & if connection is not successful it tries IP-HTTPS. So in below picture we see an IP address for Teredo interface. However as IP_HTTPS interface has IP address we can assume it is using IP-HTTPS. Technically permanently we can disable the Teredo Interface to avoid confusion.

  • Try to Ping Corporate servers.

  • Try to access corporate resources like RDP & \\UNC path for fileshare
  • In domain controller check DNS for dynamic host entries for this client. There are two entries one for IP-HTTPS and other for Teredo interface. Teredo interface can be disabled in client to stop registering in DNS unnecessarily – “netsh interface Teredo set state disabled

  • In Direct Access Server management console check Remote Client Status for details. You will find connection information.

  • Till now we have NOT used Computer Certificate. But if we have Win 7 clients & if we need few other advance functionalities we need to have computer certificate based authentication.
  • To use computer certificate
    • We have to issue computer certificate to the windows 8 machine
    • And we have to enable the same from Remote Access Management console
  • After PKI infrastructure get configured certificates can be installed manually or using auto enroll option. I have already configured PKI infra and auto enroll, you may like to check out here to know how.
  • After certificate get installed on the client make sure you verify the same to ensure all is okay.
  • On Server Side; Make sure your Enterprise or Standalone Root CA cert is installed.
  • Open Remote Access Management Console on Step 2 “remote access server” configuration click on configure; On 3rd Authentication window select use computer certificates & click on browse and select root CA certificate


  • Go back to the connected Windows 8 client and do “gpupdate /force” to apply the policy
  • And to check new firewall policies open advance windows firewall console using “wf.msc”.

  • Double click and open properties of “DirectAccessPolicy-ClientToCorp”, click Authentication Tab & under method click customize. You can see 1st Authentication method has been changed to “Computer Certificate”

  • Now disconnect the client from corporate network and hook it up to internet. You can observe Two Tunnels are created for the connection using computer certificate.


  • You can conduct same set of corporate access testing as we did in 1st section of this article without certificate

Check out next article for Windows 7 client testing.

Posted in Direct Access, Windows 2012 | 1 Comment »

Network Packet Capture without any Tool

Posted by Brajesh Panda on March 10, 2013

Here is a nice write up for boot up packet capture without wireshark or netmon but just using NETSH TRACE. I am just going to re-blog the content, credit goes to Chad Duffey, the original writer.

netsh trace start persistent=yes capture=yes tracefile=c:\temp\nettrace-boot.etl

http://blogs.msdn.com/b/canberrapfe/archive/2012/03/31/capture-a-network-trace-without-installing-anything-works-for-shutdown-and-restart-too.aspx

~~~~~~~~~~~~~~~~~~~~~~~~~

Capture a Network Trace without installing anything (& capture a network trace of a reboot)

Chad Duffey

~~~~~~~~~~~~~~~~~~~~~

To capture a network trace of a client or server without installing Wireshark or Netmon this might be helpful for you. (This feature works on Windows 7/2008 R2 and above).

The short version:

1. Open an elevated command prompt and run: “netsh trace start persistent=yes capture=yes tracefile=c:\temp\nettrace-boot.etl” (make sure you have a \temp directory or choose another location).

2. Reproduce the issue or do a reboot if you are tracing a slow boot scenario.

3. Open an elevated command prompt and run: “netsh trace stop”

Your trace will be stored in c:\temp\nettrace-boot.el or where ever you saved it. You can view the trace on another machine using netmon.

The longer version:

Since I am working with the slow boot, slow logon team this week i will do this trace for a slow boot scenario – it works fine for non reboot scenarios too, just reproduce the issue and then stop the trace.

1. Open an elevated command prompt and run: “netsh trace start persistent=yes capture=yes tracefile=c:\temp\nettrace-boot.etl” (make sure you have a \temp directory or choose another location).

 

2. Reboot the client machine.

3. Log on and stop the trace using: “netsh trace stop” (from an elevated prompt).

 If you forget to elevate the prompt you will get this:

 

 Now that you have the trace, you can take it to a machine where installing netmon is more appropriate to view the data. For customers, I capture using the netsh switch then get permission to view the data on my machine where I have netmon installed. Netmon allows us to choose .etw as a file to open as if it was an .cap file from a traditional trace.

 When you open the file you might find that it looks a bit rubbish at first:

 

 All you need to do is go to the tools > options tab so that you can tell netmon which parsers to use to convert the trace:

 

 Choose the Windows parsers and dont forget to click “set as active” before you click OK or nothing will happen.

 Now the output is ready for you to analyse:

 

 I can see above, the DHCP discover packets have been parsed correctly (and… that we arnt getting a response from a DHCP server 😉 ).

That’s about all there is to it. Hope this is useful for you.

Posted in Network | Leave a Comment »

 
%d bloggers like this: