Here's a little gem I found in a response post to an article I was reading which worked for me immediately in getting NTLM authentication to work on Exchange 2007 / Outlook Anywhere / Outlook 2007 / Windows Server 2008:
1. In Exchange Management Console, go to Server Configuration > Client Access, double-click the server name, go to Outlook Anywhere (last tab), switch from Basic to NTLM.
2. in IIS, expand your server, go to Sites > Default Web Site > RPC, then in the “Features” page double-click Authentication, right-click Windows Authentication and choose Enable.
Tuesday, February 10, 2009
Exchange 2007 on Windows 2008 Bug With IPv6
Ok, whoever let this out of the door at Microsoft without resolving it is fired. Apparently, as described in this article: http://blog.aaronmarks.com/?p=65 there is a problem with running exchange and outlook anywhere on windows server 2008 such that if IPv6 is enabled in any form, you cannot connect. The nitty-gritty details come down to the server not listening on port 6004 for some reason when IPv6 is enabled... you can try it yourself by running "Telnet localhost 6004" in the command propmpt... no response.
Long story short, enabling the registry entry detailed in that article, unchecking ipv6 on the adapter, and removing the ::1 localhost entry from the hosts file then rebooting cleared the issue right up!
(For those wondering, the issue I was having was that outlook web access was working fine, and outlook was connecting just fine inside the network, but when i tried to use outlook anywhere with outlook 2007 outside the network I would persistently get an error indicating that outlook had to be online in order to connect.)
Long story short, enabling the registry entry detailed in that article, unchecking ipv6 on the adapter, and removing the ::1 localhost entry from the hosts file then rebooting cleared the issue right up!
(For those wondering, the issue I was having was that outlook web access was working fine, and outlook was connecting just fine inside the network, but when i tried to use outlook anywhere with outlook 2007 outside the network I would persistently get an error indicating that outlook had to be online in order to connect.)
Configuring Exchange 2007 for external access to the Autodiscover service
You would like to think that going out and buying that expensive UCC Certificate then installing it properly into Exchange (as described in my previous post) would be enough, wouldn't you? Far from it. There are several follow-up steps required to properly configure Exchange 2007 (especially its Autodiscover service). Microsoft outlines a few of the commands here:
To configure the Outlook Anywhere service, run this in the EMS:
To configure the Offline Address Book service, run this in the EMS:
To configure the Exchange web services, run this in the EMS:
If using Unified Messaging, run this in the EMS:
Of course, don't forget to change the contoso stuff to your own domain. Many of these can be configured in the EMC if you are scared of command line, except for EWS... that one can only be found in the EMS. Finally, add an A record for Autodiscover and point it to the external IP of your exchange server (the same IP that mail.domain.com is pointing to) and Autodiscover should be set.
To configure the Outlook Anywhere service, run this in the EMS:
Enable-OutlookAnywhere -Server CAS01 -ExternalHostname "mail.contoso.com" -ExternalAuthenticationMethod "Basic" -SSLOffloading:$False
To configure the Offline Address Book service, run this in the EMS:
Set-OABVirtualDirectory -identity "CAS01\OAB (Default Web Site)" -externalurl https://mail.contoso.com/OAB -RequireSSL:$true
To configure the Exchange web services, run this in the EMS:
Set-WebServicesVirtualDirectory -identity "CAS01\EWS (Default Web Site)" -externalurl https://mail.contoso.com/EWS/Exchange.asmx -BasicAuthentication:$True
If using Unified Messaging, run this in the EMS:
Set-UMVirtualDirectory -identity "CAS01\UnifiedMessaging (Default Web Site)" -externalurl https://mail.contoso.com/UnifiedMessaging/Service.asmx -BasicAuthentication:$True
Of course, don't forget to change the contoso stuff to your own domain. Many of these can be configured in the EMC if you are scared of command line, except for EWS... that one can only be found in the EMS. Finally, add an A record for Autodiscover and point it to the external IP of your exchange server (the same IP that mail.domain.com is pointing to) and Autodiscover should be set.
Monday, February 9, 2009
Exchange 2007 and SSL
Installing a SSL certificate on an Exchange 2007 server is about the most unnessecarily complicated task I have come across to date. Unlike 2003, you have several names that this certificate needs to respond to, called SANs or 'Subject Alternative Names' such as autodiscover, mail (or your external fqdn), your internal dns name, and your internal netbios name. This certificate is so conveluted that most SSL certificate companies have a special process JUST for creating Exchange2007 certificates (and a REALLY special price to go with it...)
This site makes the process a little less painful by explaining in clear english step by step what needs to be done to generate the request from Exchange which you then submit to your CA (or external CA such as Entrust) so that you can get your .cer and move on.
http://exchangeninjas.com/cascert
Microsoft even links to that site, as well as other useful sources (such as vendors that provide these special Exchange certificates) in this site:
http://support.microsoft.com/?id=929395
-----------UPDATE---------------
Just another site that has proved useful to me in configuring an Exchange 2007 server with a UCC (multi SAN certificate):
http://www.sembee.co.uk/archive/2008/05/30/78.aspx
-----------UPDATE---------------
After doing some reasearch and consulting with some of my fellow techs, I found an article that describes how you can actually implement an Exchange 07 server (in a supported manner) that needs only a single name SSL certificate. The site is here:
http://www.amset.info/exchange/singlenamessl.asp
The major limitations of going this way are that you cannot use UC in Exchange 07 if you use this method, and your external DNS host MUST support SRV records (not a lot of them do...).
This site makes the process a little less painful by explaining in clear english step by step what needs to be done to generate the request from Exchange which you then submit to your CA (or external CA such as Entrust) so that you can get your .cer and move on.
http://exchangeninjas.com/cascert
Microsoft even links to that site, as well as other useful sources (such as vendors that provide these special Exchange certificates) in this site:
http://support.microsoft.com/?id=929395
-----------UPDATE---------------
Just another site that has proved useful to me in configuring an Exchange 2007 server with a UCC (multi SAN certificate):
http://www.sembee.co.uk/archive/2008/05/30/78.aspx
-----------UPDATE---------------
After doing some reasearch and consulting with some of my fellow techs, I found an article that describes how you can actually implement an Exchange 07 server (in a supported manner) that needs only a single name SSL certificate. The site is here:
http://www.amset.info/exchange/singlenamessl.asp
The major limitations of going this way are that you cannot use UC in Exchange 07 if you use this method, and your external DNS host MUST support SRV records (not a lot of them do...).
Thursday, February 5, 2009
Backup Exec agents fail to start
It is unlikely that anyone will run into the same issue I have been facing over the past few days, but I figured I should post my eventual solution to this nightmare.
The starting symptoms of the issue I had were that the backup exec agent would not start... the service would sit at starting for a minute or two, then fail saying that the service did not respond in a timely fashion... or some generic message like that. Pushing out the remote agents again, trying different versions, manually cleaning the registry... none of it worked.
The problem started with the Mariofev virus that was discovered on almost all the workstations and servers at this site. The behavior of the virus is to copy itself to any network shares that it can access, then create an autorun.inf file in the directory such that every time a user opens that directory the virus autoruns and copies itself into the unknowing users registry. The virus then appends itself to any executables it can reach in a manner of ways, including attaching itself to outgoing emails. With some virus updates and installations of Spybot, the worst of the active virus was caught and stopped from further spread.
In addition, a Trojan W32.AgentMon found its way onto several systems, particularly the ones having problems with the backup agent. The action of this Trojan is unknown, but it modifies the tcp stack with some sort of hook. This was overlooked by all the antivirus and antispyware systems installed. It was discovered that a single file named vapor.dll exists in the C:\windows\system32 directory of infected computers with a date/time stamp of the moment the Trojan activated. This dll deeply entwines itself with the winsock/tcp functions of windows causing havoc due to being poorly written (I am not sure that it actually functions, but it messes stuff up).
While working with Symantec support on the backup agent installation issues, I decided to grab a copy of process monitor from sysinternals and track all calls etc from beremote.exe (the backup exec remote agent)… and low-and-behold when beremote.exe (and soon come to find any network application) tried to establish a port it was directed to call vapor.dll first… which promptly crashed. I renamed vapor.dll to vapor.dll.old and suddenly no dns worked. Returning the file to its original name re-enabled dns. It was clear at this point that the tcp stack had been hijacked. I began thinking that it may be a good idea to try and rebuild tcp/ip on the servers to see if that fixes the issue.
Following MS article 811259, I rebuilt Winsock and reinstalled tcp/ip on the network connection, rebooting after each. After rebooting, beremote.exe started up just fine and the system could get out to the internet while vapor.dll was still renamed. Examining process monitor, no calls are made to vapor.dll anymore.
I was then able to push out the backup exec 12 agent via the normal method and start the backups running. Backup of the two systems is being performed as I write this.
The starting symptoms of the issue I had were that the backup exec agent would not start... the service would sit at starting for a minute or two, then fail saying that the service did not respond in a timely fashion... or some generic message like that. Pushing out the remote agents again, trying different versions, manually cleaning the registry... none of it worked.
The problem started with the Mariofev virus that was discovered on almost all the workstations and servers at this site. The behavior of the virus is to copy itself to any network shares that it can access, then create an autorun.inf file in the directory such that every time a user opens that directory the virus autoruns and copies itself into the unknowing users registry. The virus then appends itself to any executables it can reach in a manner of ways, including attaching itself to outgoing emails. With some virus updates and installations of Spybot, the worst of the active virus was caught and stopped from further spread.
In addition, a Trojan W32.AgentMon found its way onto several systems, particularly the ones having problems with the backup agent. The action of this Trojan is unknown, but it modifies the tcp stack with some sort of hook. This was overlooked by all the antivirus and antispyware systems installed. It was discovered that a single file named vapor.dll exists in the C:\windows\system32 directory of infected computers with a date/time stamp of the moment the Trojan activated. This dll deeply entwines itself with the winsock/tcp functions of windows causing havoc due to being poorly written (I am not sure that it actually functions, but it messes stuff up).
While working with Symantec support on the backup agent installation issues, I decided to grab a copy of process monitor from sysinternals and track all calls etc from beremote.exe (the backup exec remote agent)… and low-and-behold when beremote.exe (and soon come to find any network application) tried to establish a port it was directed to call vapor.dll first… which promptly crashed. I renamed vapor.dll to vapor.dll.old and suddenly no dns worked. Returning the file to its original name re-enabled dns. It was clear at this point that the tcp stack had been hijacked. I began thinking that it may be a good idea to try and rebuild tcp/ip on the servers to see if that fixes the issue.
Following MS article 811259, I rebuilt Winsock and reinstalled tcp/ip on the network connection, rebooting after each. After rebooting, beremote.exe started up just fine and the system could get out to the internet while vapor.dll was still renamed. Examining process monitor, no calls are made to vapor.dll anymore.
I was then able to push out the backup exec 12 agent via the normal method and start the backups running. Backup of the two systems is being performed as I write this.
Monday, February 2, 2009
Vista / Server 2008 Volume License Activation
Here's a strange one I ran across with a remarkably simple solution. When you initially install Vista or Server 2008 with a volume license key (or MAK/KMS key) then check on your activation, it will indicate that activation will occurr in a few days. When you click to activate now, it throws some kind of 'DNS name not found' error. The simple solution is to go back and click 'change product key' then re-enter the same exact key you used to install. Windows will activate fine and you are on your way!
Prerequisites for installing Exchange 2007 on Windows Server 2008
Installing Exchange 2007 and its prerequisites is a piece of cake on Windows Server 2003... install iis, add com+ and .net framework, and you are good to go. Not so much with Windows Server 2008... there are more requirements than I could count or care to remember anyway. Luckily those lovely people over at msexchangeteam.com have thrown together a zip of xml files which can be used to do all the work for you.
Here is where the strength of the new windows powershell comes in. The zip of files can be found at http://msexchangeteam.com/files/12/attachments/entry448276.aspx. Unzip all the xml files to the C: drive root, then open up the command prompt and run "ServerManagerCmd -ip xmlfilename.xml" for each xml file that matches a rule set you need. You will likely have to reboot after each one, but the powershell will tell you when its needed.
Credit goes to: http://www.petri.co.il/installing-exchange-2007-prerequisites-on-windows-server-2008.htm
Here is where the strength of the new windows powershell comes in. The zip of files can be found at http://msexchangeteam.com/files/12/attachments/entry448276.aspx. Unzip all the xml files to the C: drive root, then open up the command prompt and run "ServerManagerCmd -ip xmlfilename.xml" for each xml file that matches a rule set you need. You will likely have to reboot after each one, but the powershell will tell you when its needed.
Credit goes to: http://www.petri.co.il/installing-exchange-2007-prerequisites-on-windows-server-2008.htm
Subscribe to:
Posts (Atom)