1. Log onto the Exchange Server.
2. Start > All Programs > Exchange Management Console > Organisation Configuration > Mailbox > Offline address Book > Create a new one (Must have a different name to {Default}.
3. Delete the Old Offline Address Book.
4. Set the one you created as the default.
WAIT 20 MINUTES – If the Problem Persists
1. Log onto the Exchange Server.
2. Start > All Programs > Exchange Management Console > Server Configuration > Mailbox.
3. Select the Mailbox store in the middle section > Right Click > Properties.
4. Client Settings tab > Browse > Select the Address book you created above > OK > OK.
WAIT 20 MINUTES
Note: I’ve also fixed by creating a new mail profile – though when I switched back to the original one it was ok – so I may not have been patient enough.
Related Articles, References, Credits, or External Links
Seen in Outlook when connecting to a mailbox on an Exchange Server, its caused by using a self signed certificate OR a purchased certificate, where the internal and external names are different.
The name of the security certificate is invalid or does not match the name of the site.
Solution
Before proceeding if you have an A or CNAME record in your DNS for autodiscover then DELETE it and setup an SRV record!
1. On the Exchange Server > Start > All Programs > Microsoft Exchange Server {version} > Exchange Management Console. Issue the following four commands;
Exchange 2019 and 2016 (change the values in red)
Note: This uses the new Set-ClientAccessService commandlet, for older versions of Exchange use Set-ClientAccessServer.
Exchange 2010 and SBS 2011 (change the values in red)
[box]
Set-ClientAccessServer -Identity EXCHANGE-MAIL -AutodiscoverServiceInternalUri https://mail.publicdomain.co.uk/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity "EXCHANGE-MAIL/EWS (Default Web Site)" –InternalUrl https://mail.publicdomain.co.uk/EWS/Exchange.asmx
Set-OABVirtualDirectory -Identity “EXCHANGE-MAIL/OAB (Default Web Site)” -InternalURL https://mail.publicdomain.co.uk/OAB
Set-ActiveSyncVirtualDirectory -Identity “EXCHANGE-MAIL/Microsoft-Server-ActiveSync (Default Web Site)” -InternalURL https://mail.publicdomain.co.uk/Microsoft-Server-Activesync
[/box]
Note:If you get repeated certificate prompts for ‘autodiscover.domain.com’ that should be from ‘mail.domain.com’, create an SRV record (_autodiscover) to redirect to mail.domain.con
Outlook Anywhere Note
If you intend to use Outlook Anywhere, you may also want to execute the following command. Particularly if you use SBS, which has a habit of setting remote.publicdomain.com as the default outside name.
[box] Set-WebServicesVirtualDirectory –Identity ‘EXCHANGE-MAIL/EWS (Default Web Site)’ –ExternalUrl https://mail.publicdomain.co.uk/ews/exchange.asmx[/box]
Exchange 2007 (change the values in red)
[box]
Set-ClientAccessServer -Identity EXCHANGE-MAIL -AutodiscoverServiceInternalUri https://mail.publicdomain.co.uk/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity "EXCHANGE-MAIL/EWS (Default Web Site)" -InternalUrl https://mail.publicdomain.co.uk/ews/exchange.asmx
Set-OABVirtualDirectory -Identity "EXCHANGE-MAIL/oab (Default Web Site)" -InternalUrl https://mail.publicdomain.co.uk/oab
Set-UMVirtualDirectory -Identity "EXCHANGE-MAIL/unifiedmessaging (Default Web Site)" -InternalUrl https://mail.publicdomain.co.uk/unifiedmessaging/service.asmx
[/box]
For Small Business Server 2008
For SBS 2008 the commands are Different! (the following commands are for Exchange 2007 on SBS 2008 ONLY;
[box]
Set-ClientAccessServer -Identity EXCHANGE-MAIL -AutodiscoverServiceInternalUri https://mail.publicdomain.co.uk/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity "EXCHANGE-MAIL/EWS (SBS Web Applications)" -InternalUrl https://mail.publicdomain.co.uk/ews/exchange.asmx
Set-OABVirtualDirectory -Identity "EXCHANGE-MAIL/oab (SBS Web Applications)" -InternalUrl https://mail.publicdomain.co.uk/oab
et-UMVirtualDirectory -Identity "EXCHANGE-MAIL/unifiedmessaging (SBS Web Applications)" -InternalUrl https://mail.publicdomain.co.uk/unifiedmessaging/service.asmx
[/box]
Note: where EXCHANGE-MAIL is internal and mail.publicdomain.co.uk is external name
2. Then open the IIS Manager Expand Application Pools > MSExchangeAutodiscoverAppPool > Right Click > Recycle.
Note: You may have to enter the FQDN of the server rather than its Netbios name!!
Related Articles, References, Credits, or External Links
Original article written 04/11/11 – Updated 07/03/13
A Dynamic Distribution list, (as the name implies), maintains its membership for you. Unlike a normal static distribution list that you need to add/remove mailboxes manually.
Solution
Use PowerShell/Exchange Management Shell
1. I’m assuming you already have an OU populated with mail enabled users, in this example called Engineering.
2. Launch the Exchange Management Shell, Execute the following command, (change the values in red to match your own);
Note: In this example the ‘Alias’ can’t be created with a space in it, so it would be EngineeringDept@domainc.com.
Exchange 2013 Use the Exchange Admin Center
1. I’m assuming you already have an OU populated with mail enabled users, in this example called Sales.
2. Launch the Exchange Admin Center > recipients > Groups > Add > Specify a Name and Alias > Browse to the OU > Save.
Exchange 2007 / 2010 Use the Exchange Management Console
1. I’m assuming you already have an OU populated with mail enabled users, in this example called Sales.
2. From within the Exchange Management Console > Recipient Configuration > New Dynamic Distribution Group > Browse > Select your OU > Specify a Name and Alias > Next.
3. Specify the recipient types or click next to select All.
4. Specify any conditions > or leave blank to select none > Next > New.
5. Finish.
Related Articles, References, Credits, or External Links
Since Exchange 2007, its management tasks have been done via PowerShell, (yes even the GUI Management). Which is fine, however it runs all that PowerShell from a virtual directory that lives in the servers’ IIS webserver. When that fails or there is a problem, Exchange runs quite happily, but you can’t run the management tools.
There are a number of reasons for this to fail and a number of different error messages, I will list them as I come acoss them.
Error 1 (Seen 16/10/12)
Error: Connecting to the remote server failed with the following error message: The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: “winrm quickconfig”. For more information, see the about_Remote_Troubleshooting Help topic. It was running the command ‘Discover-exchangeserver- useWIA $true – suppressError $true’ -CurrentVersion ‘Version 14.1(Build 218.15).
I got the same when trying to access the Exchange Management Shell as well.
Update 16/10/12: I got this problem today again! It seems AVG 2012 causes this problem as well, if you have AVG installed remove it and try again.
Solution (Error 1)
1. Firstly drop to command line > then (as asked) run “WinRM QuickConfig”. Carry out any changes that it asks by simply pressing “y”.
2. Run the same command again untill it returns two positive results.
3. Start > Run > Services.msc {enter} Locate the following three services, make sure that they are set to “automatic startup” and are running.
IIS Admin Service Windows Remote Management (WS-Management) World Wide Web Publishing Service
4. Start > Administrative Tools > Expand Sites > Default Web Site > Make sure the default web site IS STARTED.
THIS WAS MY PROBLEM! If you can see the green start arrow then its NOT started.
5. When I attempted to start the default web site I got the following error:
Error: The process cannot access the file because it is being used by another process. (Exception from HRESULT: 0x80070020).
Essentially one or both of the two comms ports that IIS uses (Port 80 HTTP and Port 443 HTTPS) have been taken by another process or program. Have a common sense check, what’s been installed on this server that might have a “web portal”? UPS software, AV software, another web server like Apache for example?
To find out what process is using the port
6. Close down any open windows that you have on the server. At command line issue the following two commands:
The fist checks for programs using port 80, In my case there were none, the second command checks port 443, heres my culpritt. All I know at this point is it’s PID (in the example below 4852).
7. To find out what that PID is, right click your Task bar > Launch Task Manager > Processes Tab > View > Select Columns.
9. Sort the PID column (by clicking on the column title) locate the PID in question, find out what it is. Once you know that stopping it will not harm the server, then simply right click and “End Process Tree”.
Note: Some legitimate important Windows processes might be using these ports like “lsass” and “system”.
10. Now you should be able to start the default website, and the Exchange Management Console should open correctly.
WARNING: You have not fixed the problem! (Just identified it), the software that hijacked the IIS ports needs uninstalling, or changing so that it uses a different port.
Error 2 (Seen 02/05/13)
Connecting to the remote server failed with the following error message: The WinRM client… cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid. For more information, see the about_Remote_Troubleshooting Help topic. It was running the command ‘Discover-exchangeserver- useWIA $true – suppressError $true’ -CurrentVersion ‘Version 14.1(Build 218.15).
And from the Exchange Managent Shell;
Other Symtoms;
Attempting to open OWA gives a 500 – Internal server error. (If that’s the only problem and it’s SBS 2011, make sure the ‘Microsft Exchange Form Based Authentication’ service is running).
Solution (Error 2)
I spent an entire afternoon fighting with this error on an SBS 2011 server! Every post I found on the internet did NOT fix it. Not even this one (which was so close) but my envirnment variables were correct
The EMTShooter did not help either, I checked it’s recommendations. and they were all correct.
The bottom line is: This is an IIS problem not an Exchange one, the site I was at had done a lot of work on this server and just installed some third party software, (that may or may not have changed some IIS configuration settings). So I connected to another working SBS 2011 Server and copied the contents of the c:inetpubwwwroot folder to the affected machine (back it’s contents up first!). Then run the following command;
[box] iisreset [/box]
If you don’t have access to a working SBS 2011 server, here you go, (you owe me a vodka!)
Error 3 (Seen 30/04/14)
“The attempt to connect to http://server.domain.com/PowerShell using “Kerberos” authentication failed: connecting to remote server failed with the following error message : The WinRM client cannot complete the operation within the time specified. Check if the machine name is valid and is reachable over the network and firewall exception for Windows Remote Management service is enabled. For more information, see the about_Remote_Troubleshooting Help topic.”
Seen on Exchange (with or without service packs) when you access the internet through a proxy server. Note: Exchange does NOT take its proxy settings from Internet Explorer.
Solution
1. To prove that the proxy is the problem drop to command line and issue the following command:
[box]netsh winhttp show proxy[/box]
If it says “Direct Access (no proxy server)” and you have a proxy server then that’s your problem.
2. Issue the following command:
[box]netsh winhttp set proxy proxy-server=”http={proxy IP}:{port};https={proxy ip}:{port}” bypass-list=”*.YourDomain.com”[/box]
3. Note: If at this point it all goes wrong (If you get it wrong, then the Exchange Management Console wont open! test it to make sure). To revert back to “no proxy”, issue the following command:
[box]netsh winhttp set proxy proxy-server=”http={proxy IP}:{port};https={proxy ip}:{port}” bypass-list=”*.YourDomain.com”[/box]
You only do this if it’s broken something!!
4. All being well your certificates should now display correctly.
Related Articles, References, Credits, or External Links
