Monday, October 25, 2010

Exchange 2010: Troubleshooting the Exchange services

Introduction
These are some resolutions that may assist when you are unable to start the Exchange services.

1. Check the event log. If you are receiving a number of DSAccess warnings then you can bet that it is related to Active Directory. Check for event 2080 to see which domain controllers are listed. Ensure they can all be pinged. Check in the DSAccess warnings to see which domain controllers it is trying to access. Try pinging these domain controllers to ensure they are online and accessible.

2. If it is trying to access DCs that are not online then you may have enabled staticdomaincontroller settings on the Exchagne server that is failing. You can see the settings by running Get-ExchangeServer | Format-List.
Unfortunately even if something is set as a static domain controller, it doesnt show up. Try resetting them all to $NULL even if they already appear to be so. You can also try statically exluding the domain controllers that are non-existent.

3. Check that IPv6 is either enabled, or properly disabled via the registry. Microsoft has articles on how to do this.

4. Check that the Exchange server is member of the correct groups in Active Directory.

5. Run BPA scans on the affected server to check for configuration issues.

Wednesday, October 20, 2010

CMD As User

This application (CMDAsUser) allows you to run installations or applications as the SYSTEM account and see an interactive desktop. This can be useful in testing applications that are deployed through a product such as ITCM or SCCM using the SYSTEM account.

I found that the following privileges were required even if the calling account has Administrative rights: -

"Act as part of the operating system" (SeTcbPrivilege),
"Bypass traverse checking" (SeChangeNotifyPrivilege),
"Increase quotas" (SeIncreaseQuotaPrivilege),
"Replace a process level token" (SeAssignPrimaryTokenPrivilege).

This is the recommendation on the Internet, however personally I added "Act as part of the operating system" and "Replace a proecss level token" and it works.

Tuesday, October 19, 2010

Configuring and troubleshooting WPAD

This is not an exhaustive reference to WPAD. WPAD provides automatic configuration to Internet clients such as the firewall client and Internet Explorer. Internet Explorer has a number of options to either manually specify the WPAD.dat file or to automatically detect the wpad.dat file using either DHCP or DNS. When both DHCP and DNS are configured with the WPAD URL, DHCP clients will only try the DNS URL if the URL has not been configured in DHCP.

When using TMG, WPAD can be distributed in two ways: -
1. By using the TMG default mechanism. This does not use IIS in any way.
2. By manually distributing the WPAD file on an IIS server.

Manual distribution via IIS
To distribute via IIS, firstly attain the WPAD file that you want to distribute. It should be called wpad.dat. Place in in the IIS website. In order to allow clients to download wpad.dat, you will need to add a MIME type into the IIS website as follows:
Extension: .dat
Content Type(MIME): application/octet-stream

If you are unable to download the WPAD.dat: -
1. Check that the MIME type is correctly configured. If you rename the extension to .html then does it become downloadable? If so, then the MIME type is not correctly configured.
2. Perform basic IIS troubleshooting to ensure it is serving pages correctly.

Distributing via TMG
When distributing via TMG, the WPAD file is automatically created. It is administered by changing the settings within the TMG console. You can select the port that TMG will distribute the WPAD file on. You should be able to acces the WPAD using the URL http://TMGserver/wpad.dat.

If you are unable to download the WPAD.dat at all then ensure the TMG WPAD service is not conflicting with any of the following:
1. An IIS server on the same server. If you are serving WPAD on port 80 and IIS is also configured to listen on port 80 then you will not be able to access WPAD. Stop the IIS website and change the port from 80 to 81 (just in case someone starts it up again). The assumption here is that IIS is not required for any purpose. TMG itself does not require IIS to be started.
2. A Web Listener configured in TMG to listen on the same port and on the same network. For example, if a Web Listener is listening on port 80 on the Internal interface, then you will not be able to publish WPAD on port 80.
3. Another third party service is listening on port 80.
4. A firewall may exist between the client and the TMG server.

If you are able to download the WPAD.dat but clients are not able to use it to access the Internet - it could be due to a bug in TMG 2010! If you configure VPN access to use an internal DHCP server, it will assign an internal IP address to the RRAS interface on the TMG server. VPN clients will also receive an internal IP address. Because the RRAS IP address is in the range of IP addresses listed on the "internal" network object, TMG will generate the WPAD.dat using the RRAS IP address. This means clients will be unable to connect to the Internet. Check the WPAD.dat for the IP address that is used. The workarounds are as follows: -
1. Use a static pool for VPN clients instead. This means the IP addresses are not in the internal IP address range.
2. Maintain the WPAD.dat on an IIS website - this requires manually updating the WPAD.dat each time a change is required.
3. 3. Run a short vbscript on the server that makes TMG generate the WPAD using the FQDN of the server instead. You then need to make sure that this FQDN resolves to the correct IP address for WPAD clients. This issue is mentioned here http://social.technet.microsoft.com/Forums/en-US/ForefrontedgeIA/thread/2c4e342f-0ab7-4cd7-b007-0f2b0c559704. The solution script is here http://blogs.technet.com/b/isablog/archive/2008/06/26/understanding-by-design-behavior-of-isa-server-2006-using-kerberos-authentication-for-web-proxy-requests-on-isa-server-2006-with-nlb.aspx.

This is the script that needs to be run on the TMG server. It causes the firewall service to restart shortly after the script is run. This script has been tested by us and confirmed to resolve the issue.

Const fpcCarpNameSystem_DNS = 0
Const fpcCarpNameSystem_WINS = 1
Const fpcCarpNameSystem_IP = 2

Dim oISA: Set oISA = CreateObject( "FPC.Root" )
Dim oArray: Set oArray = oISA.GetContainingArray
Dim oWebProxy: Set oWebProxy = oArray.ArrayPolicy.WebProxy

If fpcCarpNameSystem_DNS = oWebProxy.CarpNameSystem Then
WScript.Echo "ISA is already configured to provide DNS names in the WPAD script"
WScript.Quit
End If

oWebProxy.CarpNameSystem = fpcCarpNameSystem_DNS
oWebProxy.Save true

WScript.Echo "ISA was configured to provide DNS names in the WPAD script..."

Friday, October 15, 2010

Troubleshooting

Following are some good resources on universal troubleshooting:

The Universal Troubleshooting Process (UTP)
http://www.troubleshooters.com/tuni.htm