$password = $cred.GetNetworkCredential().Password
#Test autodiscover exchange 2010 password#
$str = Read-Host -AsSecureString "Enter password for $username" $str = Read-Host "Enter username for request" If( -not ( $useDefaultCredentials -ne $null -and $useDefaultCredentials.IsPresent ) ) $uri = ' + $hostname + '/Autodiscover/Autodiscover.xml'
# will attempt to figure out what is going on. # No warranties, express or implied, are available. # michael at TheEssentialExchange dot com # This is not a list of all possible issues. # Misconfigured permissions on the reverse proxy # Misconfigured (or missing) Service Connection Point (SCP) # Misconfigured permissions on the Autodiscover virtual directory # If this script works, but your Exchange autodiscover does not, there # The usage for useDefaultCredentials is explained within the source # autodiscover is for Exchange ActiveSync, versus the request that is # If you specify the "mobile" argument, then the request sent to # all three of username, password, and emailAddress. # In general, you must specify either useDefaultCredentials OR specify # of the Microsoft provided tools give you that flexibility.
# This script allows you to test autodiscover to a specific host. # your real autodiscover host, the responses will be the same. # specified host returns as an autodiscover response. # Instead, given a particular hostname, this script determines what the # This script does NOT behave exactly the same as Outlook autodiscover or # This script performs a basic test of Exchange autodiscover for a given While I have it working today, it’s not a pretty script. I am developing a script that works “the same way” as Outlook is documented to work for autodiscover – with more insight to the various steps. Read the source of the script below for the most common issues. If the internal test fails – then you may have several items to check. If an internal test succeeds, but an external test fails – this points you to load-balancer/firewall/router. This script will allow you to test internally or externally (given that your firewall/router has the appropriate NAT forwarding/translation rules and DNS is properly configured). If it succeeds, but your overall autodiscover fails, then you have a far reduced set of things to investigate, in order to repair your autodiscover deployment. The script below allows you to test autodiscover to a specific server. This PowerShell allows you to work “from the inside to the outside”. However, it works “from the outside to the inside”. Microsoft does provide the Microsoft Connectivity Analyzer which can (among other things) give you detailed information about your autodiscover situation. Then, repairing autodiscover can be surprisingly challenging. Exchange Autodiscover is deceptively simple.