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..."

Troubleshooting

Following are some good resources on universal troubleshooting:

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

Exchange: Outlook and OWA attachment issues

Outlook client does not display attachments

There are a number of reasons why this might be the case.

• See http://knicksmith.blogspot.com/2007/03/exchange-2007-and-outlook-2003-where.html. An issue was resolved by Microsoft in Exchange 2003 Service Pack 1 where Exchange 2007 was incorrectly causing Outlook 2003 to hide inline attachments. Even though you could not see the attachment, if you flagged the email, or clicked forward on the email, the attachment would appear correctly. Also if you selected Save attachments from the file menu, it would still save the attachments. OWA is not affected by this.
• See http://social.technet.microsoft.com/Forums/en-US/exchangesvrclients/thread/478c326b-486b-461c-9141-dd544b245c75. Symptoms: You can see the attachment in OWA but not in any of the current versions of Outlook. Outlook blocks the attachment completely and there is no way to retrieve it through this interface. This is also more likely to happen when an inhouse application has been programmed to send email with attachments. if the MIME is formatted incorrectly then Outlook will not display it. RFC 2387 describes the intended use of multipart/related:
  http://www.ietf.org/rfc/rfc2387.txt:
  "The Multipart/Related media type is intended for compound objects consisting of several inter-related body parts. For a Multipart/Related object, proper display cannot be achieved by individually displaying the constituent body parts."
  Steps to resolve this issue involve changing the MIME header to Multipart/Mixed instead of Multipart/Related. Multipart/Related will cause the attachment to be considered inline by Outlook. As there is no reference to the attachment in the body, it will then effectively be ignored. OWA has more smarts and is able to determine if an attachment is really inline or not. If it finds no reference to the attachment in the body of the email then it displays the attachment as a separate entity.

Exchange 20xx: Autodiscover and availability Issues

You receive the message: Allow this website to configure server settings?
You test e-mail autoconfiguration and it fails for no apparent reason.

The reason you receive the above error message is because the autodiscover website has been configured to redirect to a different website. For example, you might want to use https://webmail.domain.com/autodiscover/autodiscover.xml as your autodiscover URL. In this case you would redirect http://autodiscover.domain.com/ to that URL.

You may also receive this message if your autodiscover SSL website is not working correctly and fails. In this case, it will try http:// instead of https://. If you happen to have http:// redirected to https:// then you will also receive this message as this counts as a redirect.

You should be able to click the "Dont ask me about this website again" to make the message disappear for good.

Troubleshooting autodiscover messages:

• Use testexchangeconnectivity.com. It is there to help you find out if problems exist in Exchange client access from the Internet.
• If the user's primary email address is @domain1.com then is there an autodiscover record configured for this domain (either via an autodiscover website, redirection website, or a SRV record)
• Check the version of Outlook being used. If it is Outlook 2007 SP1 or RTM then the first thing to do is to update to Outlook 2007 SP2. This can fix a number of issues and also fixes an issue where the e-mail autoconfiguration autodiscover test errors out with 0x8004005 immediately after a line where it appears to succeed (returns a 500 response).
• Check whether the workstation is joined to the domain. This can determine the status of password storage and determine how you go about troubleshooting this issue.
• Check the user account credentials stored in the Windows profile. If credentials are stored for Exchange and yet the password has been updated since, you may get a series of password prompts and possibly autodiscover prompts appearing. In Windows XP you can access this by typing UserControl2 into the Start-->Run dialog box.

Using multiple email domains can affect autodiscover
Another issue that can occur with autodiscover is if your organisation uses different email domains. If autodiscover is configured on http://domain.com/ and the email address for the user is @anotherdomain.com then autodiscover will not be resolved. You might want to create SRV records for these domains to redirect users to the autodiscover website.

Authentication on web services and autodiscover virtual directories can affect autodiscover

Another issue that may occur if autodiscover is receiving errors (0x8004005) and Out of Office is returning an error "the server is unavailable". This may be because Windows Authentication may not be enabled on the web services:

get-webservicesvirtualdirectory | Set-WebServicesVirtualDirectory -WindowsAuthentication:$true

How Autodiscover works

A client attempts to connect to the SCP to get an autodiscover URL. If the client is not domain-connected then this will fail.

A client attempts to connect to domain.com and autodiscover.domain.com based on the user's primary SMTP address. It tries https first and then http.

See http://technet.microsoft.com/en-us/library/bb124251.aspx for a more detailed description.

Basic troubleshooting steps

When auto-discover stops working, you may find that your Out-Of-Office and Free/Busy (availability) stop working too.

Start the Outlook client. Hold CTRL and right click the OL icon in the system tray. Select Test Email Auto-configuration. Enter the email address and password. Select "Use Autodiscover" but deselect all the Guessmart checkboxes. Click Test. On the XML tab, ensure it is connecting to the correct autodiscover URL. You may receive one of the following errors as defined by Microsoft.

0x80072EE7 – ERROR_INTERNET_NAME_NOT_RESOLVED
This error is usually caused by a missing host record for the Autodiscover service in the Domain Naming service.

0X80072F17 – ERROR_INTERNET_SEC_CERT_ERRORS
This error is usually caused by an incorrect certificate configuration on the Exchange 2007 computer that has the Client Access server role installed.

0X80072EFD – ERROR_INTERNET_CANNOT_CONNECT
This error is usually caused by issues that are related to Domain Naming service.

0X800C820A – E_AC_NO_SUPPORTED_SCHEMES
This error is usually caused by incorrect security settings in Outlook 2007.

- If this is a workstation connected to the domain and able to reach Active Directory, ensure it gets a URL from the SCP in Active Directory and is able to connect to it. If it retrieves a URL but fails in using it, check that the URL can be accessed by pasting it into an Internet Explorer window. It may be that TMG or the proxy is blocking access to that server. The resolution in this case may be to add the URL to the proxy exceptions list.

- If this is a workstation that is not domain-connected, check that the correct URL is returned. If not, it has not been configured correctly as the external URL on the internet facing CAS server(s). If the URL is correct then try to paste the auto-discover URL into Internet Explorer and see if the autodiscover XML pops up.

- If you have an issue with seeing free/busy data for other users then try to enable logging in Outlook 2007 > Tools > Options > Other > Advanced Options > Select Enable logging (troubleshooting) > OK > Restart Outlook > Try to view free / busy information for another user > Go to the %temp% folder and open olkdisc.log file and locate the files in the olkas directory. These files can often provide information about which service is not functioning correctly.

- If you have an issue with seeing free/busy data for other users then review the event log for event id's: 4001, 4003, 4005, and 4011. Possible solutions for these errors are contained at http://technet.microsoft.com/en-us/library/bb397225(EXCHG.80).aspx

- Use the test-OutlookWebServices cmdlet to troubleshoot the availability service. For example, Test-OutlookWebServices -id:user1@mydomain.com -TargetAddress: user2@mydomain.com

- If you have an issue with seeing free/busy data for other users then check if there are any cross-forest timeout issues. Details are contained in the URL http://technet.microsoft.com/en-us/library/bb397225(EXCHG.80).aspx

- Check the SCP point in Active Directory Sites and Services by enabling the "View Services Node" option. It is under Services > Microsoft Exchange > Org Name > Administrative Groups > Admin Group Name > Servers > Server Name > Protocols > Autodiscover. These SCP points can be administered using the Set-ClientAccessServer cmdlet.

- If the issue is with external users, then use the website http://www.testexchangeconnectivity.com/ to check that your configuration is correct.

- If you have issues and you are using multiple SMTP namespaces then you will want to check out http://www.msexchange.org/articles_tutorials/exchange-server-2010/management-administration/exchange-autodiscover.html

- Check that IIS is started on all servers

- Check that the OWA application pool, OAB application pool, and EWS application pool are all running and started with no errors.

- If you receive an authentication error (such as 500 service not availabile or 400 login time-out) then you may need to rebuild the virtual directories.

Verify Configuration
Ensure you have configured the following: -
- Configure your internal URLs for all virtual directories. These should be automatically configured as the server name. Configure external URLS only on your Internet facing CAS servers. See http://technet.microsoft.com/en-us/library/bb691323(EXCHG.80).aspx for details on how to do this. The external URL will either be the name of a CAS server or an NLB that is sitting in front of a number of CAS servers.
- Configure certificates on each Exchange servers and TMG servers as required. These should be trusted by clients.
- Add all Exchange CAS servers to a proxy exceptions list - generally either using WPAD or Group Policy.

What would I have on my computer?

Microsoft Office (or Open Office if I want a free version)
Microsoft Visio and Project
iTunes (for the iPhone)
VMWare Workstation or Virtual PC
PDF 995 (Print to PDF documents)
Adobe Acrobat Reader
Infrarecorder (CD Burner)
Shockwave / Flash Player
Comodo Firewall and AV
Daemon Tools
Firefox
Notepad++
Irfan Viewer
Open Movie Editor
FileZilla
CMD Prompt Here
.Net Framework

Active Directory: Reset the DSRM password in Active Directory

If you are still able to log into the server through normal operation, you can reset the DSRM password using NTDSUTIL. See http://support.microsoft.com/kb/322672 for Windows Server 2003.

If you cannot access the server in normal mode, you will need to use a hacking tool to reset the DSRM password on that server. Try using a tool such as http://www.ubcd4win.com/ or http://www.hiren.info/pages/bootcd.

Outlook 2007: Outlook prompting for password issue

Symptoms: Outlook 2007 clients are prompting for password when connecting to Exchange 2007.

Possible solutions if affecting single users:

• Open the profile settings and make sure there is no checkbox in "Always prompt for user name and password" on the Security tab
• Check credential manager. It may be storing an incorrect password for the user and Outlook may be using this to connect to Exchange. Run control userpasswords2. On the Advanced tab, select "Manage Passwords". Remove any entries to the Exchange server. Alternatively, erase the server name and enter "S1" or the simple name of your global catalog server and leave the password blank. If prompted again, enter your username and password and check off "remember my password" one last time and it should not prompt again.
• Try typing in the username by including the domain name. i.e. DOMAINNAME\Username. This has been known to resolve the issue.
• In the task tray, hold down CTRL Key and right click the Outlook icon and select Test Email Auto Configuration. Uncheck Use Guessmart and Secure Guessmart Authentication. Click Test. When the test is completed, view the XML results.
• Check that the autodiscover URLs are in the proxy exceptions list.
• Open the following path: In Vista: \Users\YourUserName\AppData\Roaming\Microsoft Once open you will see numerous folders including a “protect” folder. Delete the “protect” folder. When you have deleted the protect folder, restart Outlook. You will be requested to enter your password again, but it will be the last time.
  Check that an Internet security product is not blocking a port.

Possible solutions if affecting a large number of people:

• Open IIS on theExchange server and checked the following directories under the default website: the root site, oab, autodiscover. Under the directory security tab, click Edit in the Secure Communications section. If you have "require SSL" checked and the 128 bit encryption, but under Client Certificates, it is set to ignore, then this may be the problem. Change this to "Accept" for each of the folders and restart IIS. This may not be a satisfactory solution for everyone.
• Try to connect to the autodiscover URLs listed in the SCP and in Exchange Management Console.
• Make sure the OABurl is set to https and not http
• In the task tray, hold down CTRL Key and right click the Outlook icon and select Test Email Auto Configuration. Uncheck Use Guessmart and Secure Guessmart Authentication. Click Test. When the test is completed, view the XML results. If the URL for the OAB is starting with HTTP instead of HTTPS then you may need to change this from the Exchange Management Console. Do an iisreset and test again.
  Make sure integrated security is enabled on the virtual directories where required.
• Ensure Offline Address Book has been migrated to Exchange 2007.
• Look at the properties of the autodiscover virtual directory and ensure a version of ASP is selected. If none is selected, clients may be prompted for password.
• Ensure Windows authentication is enabled on the Autodiscover virtual directory.
• See http://support.microsoft.com/kb/236032

If the problem exists when using RPC over HTTP:

If you are working RPC over https you are using or basic, or NTLM authentication, you need to be sure you are working NTLM. Now in order to ensure that outlook not uses any cached password we need to do the following. Go to Control Panel>User AcountsPress on Advanced Tab button. Click on Manage Passwords button. Review stored passwords , and if you see IP address of your mail server you should delete it.
Now we need to patch te registry
Click StartRun
Type regedit and press enter
Go to HKLM\SYSTEM\CurrentControlSet\Control\Lsa\
Find lmcompatibilitylevel DWORD parameter
Double-click on it and change its value to 3