A behavior that changed with the introduction of Server 2008 is that the source IP address on a NIC will always be the lowest numerical IP. So that whole idea of your primary IP being the first one you put on the NIC – throw that idea out the window.

For example, let’s say we build a new Exchange server and configure the NIC with IP 10.0.0.100. This IP is registered in DNS and the server uses this IP as the source when communicating with other servers. Our fantastic network administrator has also created a NAT rule on the firewall to map this IP to a particular public IP for outbound SMTP so that our PTR lookups match up.

But now we want to add another IP for a custom receive connector and the network admin hands you a free IP which happens to be 10.0.0.50. You add this as an additional IP on the NIC and voila – you have a couple issues:

• You just registered two names for the same server in DNS if dynamic registration is enabled.
• Your server is now sending all outbound traffic from 10.0.0.50! (because 50 is lower than 100)

One of these is easily solved – just turn off dynamic registration and manually create the DNS records for the server. The other one is a little trickier because Server 2008 and 2008 R2 will still be sending traffic as the 10.0.0.50 IP. In the case of Exchange, this could create some ugliness for outgoing SMTP because now your firewall is not NATing to the correct public IP and you start bouncing mail due to PTR lookup failures.

Fortunately, we have a way to tell Windows not to use the lower numbered IP as a source address by adding the IP via the netsh.exe command. For Server 2008 SP2 and 2008 R2 RTM we need to apply a hotfix first. 2008 R2 SP1 included this fix by default so it is no longer required. Without the hotfix or SP1 you’ll find netsh.exe does not display or recognize the special flag.

Hotfix Downloads:

• 2008 SP2: http://support.microsoft.com/kb/975808
• 2008 R2 RTM: http://support.microsoft.com/kb/2386184/

The key to this is the IP address must be added via netsh.exe with a particular flag. So if you’ve already added the IP address via the GUI you’ll need to remove it first. After that, use this command to add the secondary IP:

netsh int ipv4 add address "Local Area Connection" 1.2.3.4/24 SkipAsSource=true

The SkipAsSource flag does two things – first, it instructs Windows not to use this IP as a source IP for outgoing traffic. And secondly, it prevents the registration of this IP in DNS if dynamic registration is enabled. Two birds with one stone!

You can always view the status of the IPs and their SkipAsSource status with the following command:

netsh int ipv4 show ipaddresses level=verbose

For starters, we followed the steps outlined on Technet. After we had successfully detached and attached all databases and ran the LCSCMD.exe step, we launched the Create Pool wizard and attempted to plug in the info for the new SQL cluster. We got this error back:

An error occurred during the pool backend detection:

Pool backend discovery failed.

Invalid database parameter.

I double-checked the server name, instance, and FQDN and all looked well. We verified the SQL server was accessible via TCP 1433 and no firewall rules were preventing access, so the error didn’t make a lot of sense. Obviously there was some kind of parameter that the wizard GUI was not cool with. I thought maybe this was the SQL allow updates issue, but that solution had no effect on this error. There was definitely some validation check the UI was failing on against our new DB.

Since I couldn’t locate anyone else with this issue I figured my options were to call PSS and extend this process by a few hours, or pull out the ol’ LCSCMD.exe again and try this operation via command line. The Create Pool wizard really is just collecting a bunch of information and then using it to execute the LCSCMD.exe commands in the background so while doing it manually is not fun, it works just as well.

The entire syntax for LCSCMD.exe can be found on Techet, but here is the command we ended up running. Please note, conferencing archiving was not implemented so that paramter is not present.

LCSCMD.exe /Forest /Action:CreatePool /PoolName:MyOCSPool /PoolBE:MySQLServer.ptown.local\OCSInstance /PoolFQDN:MyOCSPool.ptown.local /InternalWebFQDN:MyOCSPool.ptown.local /ExternalWebFQDN:PublicOCSWebComponents.confusedamused.com /RefDomain:ptown.local /ABOutputlocation:\\MyFileServer\AddressBook /MeetingContentPath:\\MyFileServer\MeetingContent /MeetingMetaPath:\\MyFileServer\MeetingMetadata /AppDataLocation:\\MyFileServer\AppData /ClientUpdateLocation:\\MyFilerServer\ClientUpdates /DBDataPath:"D:\Databases" /DBLogPath:"L:\Logs" /DynDataPath:"D:\Databases" /DynLogPath:"L:\Logs" /ABSDataPath:"D:\Databases" /ABSLogPath:"L:\Logs" /ACDDataPath:"D:\Databases" /ACDLogPath:"L:\Logs"

After running the command manually it succeeded with absolutely no issues. The new cluster has been running for over a week now without any issues so I think this is an problem specific to the UI. I’m not sure exactly what causes it, but our environment was running SQL 2008 with SP2 on top of a 2008 R2 SP1 operating system.

As a sidenote, this process seems to undo any changes made by the OCS2009-DBUpgrade.msi patches. You’ll need to re-run the patch version which lines up with your FE patch levels before the FE services will be able to start.

You can see my installer completed in about 12 minutes, which is pretty damn cool. This was a VM with 3 GB of RAM with its VHD on a RAID 10 set. Imagine if this was a production machine with a real amount of RAM.

]]> http://www.confusedamused.com/notebook/installing-exchange-2010-in-20-minutes-or-less/feed/ 0 http://www.confusedamused.com/notebook/oab-never-downloads-for-outlook-2007-clients-with-exchange-2007-on-server-2008/ http://www.confusedamused.com/notebook/oab-never-downloads-for-outlook-2007-clients-with-exchange-2007-on-server-2008/#comments Thu, 26 Feb 2009 06:11:03 +0000 Tom Pacyk http://www.confusedamused.com/notebook/oab-never-downloads-for-outlook-2007-clients-with-exchange-2007-on-server-2008/ Update: This post gets a lot of traffic, but I want to be clear the first step here is no longer required. Simply perform the solution at the end of the post.

C:\Windows\system32\inetsrv\appcmd.exe set config /section:system.webServer/security/authentication/windowsAuthentication /useKernelMode:false

Second – I had enabled a redirect at the Default Web Site root to dump clients to the /owa folder gracefully using the Microsoft methodology at Technet. If you read the procedure you’ll notice setting the redirect at the root sets the same redirect on every single virtual directory. So, you need to go in to each virtual directory and undo the change you made for the root. This works fine, or appears to until your Outlook 2007 client tries to download the OAB and hangs forever.

I brightly plugged the URL to the OAB.XML file into IE and was greeted with a 500 – Internal Server Error message without an authentication prompt. That didn’t seem right. After some searching I realized the reason why Outlook hangs forever is that it tries to hit this URL, gets denied, uses some back-off logic, and tries again. I believe the back-off gets longer and longer each time it fails.

What happens is that when you disable that redirect for the OAB virtual directory IIS 7 generates a web.config file in the C:\Program Files\Microsoft\Exchange Server\ClientAccess\OAB folder. This seems logical, as it overrides the redirect at the root level, and is necessary. Unlike every other web.config that is generated in the other folders like Autodiscover and OWA, Authenticated Users do not have read access to the file. This is why Outlook and IE can’t even access the /OAB virtual directory.

The fix is pretty easy. Open the web.config in the OAB folder, and give Authenticated Users both the read and read and execute permissions. Run a iisreset /noforce on the CAS server to bounce IIS. Just for good measure, on the client side I wiped out the Outlook profile, and the contents of the %USERPROFILE%\Local Settings\Application Data\Microsoft\Outlook folder. Once I recreated the profile the OAB downloaded just fine. All in a day’s fun…

Hallelujah. Some decent support for Exchange on the Mac side. Significant changes include:

• Enhanced Autodiscover service to keep user account settings up to date after the account setup.
• Synchronization between Exchange Server and Entourage 2008 Notes, Tasks, and Categories.
• Addition of an Enable Logging (troubleshooting) preference, to log all events that can be used as diagnostic information.
• Use of attachments in Entourage for Exchange calendar events.

At a minimum you need Entourage 2008, but what version of update rollups your Exchange server needs to be at is a little confusing. The blogs say Update Rollup 4, but when you fill out the survey to get in the beta it says Update Rollup 5. I guess I’d go better safe than sorry and assume Update Rollup 5 at this point.

You can sign up for the beta here: http://www.microsoft.com/mac/itpros/entourage-ews.mspx

So when I finally fired up task manager in the 2008 machine I found the culprit: TrustedInstaller.exe was consuming 80-90% of the guest OS CPU. After some investigating, apparently this process manages software updates within Vista/Server 2008 platforms. Since I’m only planning on running this as a test OS I just went ahead an killed the process. I don’t need no stinking updates! We’ll see if this adversely affects anything else, but at least I can now run the VM at a reasonable speed.