Recently I deployed my first Exchange 2007 server on Windows 2008 for one of the companies I work with. During the process of deploying the server we found out that the new Windows Server Backup that is included in Windows Server 2008 does not have the capability to backup the Exchange Information Stores in the same fashion that the old NTBackup from Windows 2003 did.
After doing some research I discovered that Microsoft did this by design, and recommends that those who previously using NTBackup to backup Exchange move to their System Center Data Protection Manager product. While this did not make me happy, it clearly did not make the Exchange Admin community jump for joy. There was a big outcry, complaining at Microsoft for taking such core functionality out of Windows. In June of this year, Microsoft relented and promised to deliver an update to Windows Server Backup to add this functionality back in. It is now November, and it has not happened yet.
In the mad scramble to find an alternative way to make a simple backup of the Exchange Info Stores I stumbled upon a post on the Exchange Team Blog, by a poster named “Phil Carter” that details a method of using the old NTBackup from Windows Server 2003 on Server 2008 without a hitch. This sounded too good to be true, it could not possibly work, why would Microsoft not simply distribute the old backup utility to solve this problem. However, after considering the alternatives of buying and expensive 3rd party backup utility, or deploying DPM (and the required, dedicated Windows server to go with it) I decided to give it a go.
Here is what I did:
1) Load up a Windows 2003 x64 system. The x64 part is important, as you should be running Exchange on a x64 platform (unless you are using an Itanium), and you must use matching binaries for this. I used a Virtual Machine for this.
2) Copy the ntbackup.exe, ntmsapi.dll, and vssapi.dll from C:\windows\system32 into a new folder.
3) Burn the new folder you created containing the copied files to a CD, or copy it to USB drive. You can also copy it over the network to your Windows 2008/Exchange 2007 Server to skip the next step.
4) Copy the folder from the CD or USB drive to your Windows 2008/Exchange2007 server.
5) Launch Ntbackup.exe. Select the Information Stores as you would normally under NTBackup and start your backup.
After it completes you should have a quick and easy Exchange 2007 Backup on Windows 2008. This method even purges your transaction logs properly. I have even verified this method works properly, by attempting to restore from the backup. It works without a hitch.
This method is great for small shops that happen to be running Exchange 2007 on Windows 2008, and do not have the need or resources for yet another Windows server just to run backups as DPM requires. For larger shops, I actually do recommend DPM over other 3rd party tools, as its method of doing replication works really well.
The Tech blogs are all a buzz this morning with a revelation that Microsoft may be considering adopting WebKit to use as the rendering engine in Internet Explorer. While I hate to rain on their parade, this will not happen, at least any time soon. Considering that Microsoft is in the process of preparing to release IE 8 within the next year or so, and the release cycle of Internet Explorer has been far and few between it will likely be years off before we see another release of IE.
In addition to the long release cycle, Microsoft has invest significant amounts of money and time into .NET and its tight integration with IE, which is notorious for not working with or rendering well with other browser rendering engines. Even if Microsoft went entirely AJAX for all of their web-based products, there is massive amounts of code from other developers out there that are tailored to run on IE. Microsoft would even have to rework many of their core products to use another rendering engine, an example is Outlook Web Access. OWA is puedo AJAX-based, but it still maintains separate versions for IE and other browsers, not to mention that many of the MMC snapins rely on IE for rendering key components. Would they have to rework these too? Finally, could you imagine Microsoft working on an open source code base that they share with not only the general public, but Apple, and Google?
What I could see Microsoft doing in the short term to test the waters is releasing an unofficial addon that allows you to manually choose to render a page in WebKit. This is much like the IE 8 betas have for rendering as if it were IE7. This would allow them to gauge the demand, as well as test functionality with a new engine, without having to rework, much of their core products. If this were to happen I could see it being released much like the PowerTools have always been released, without official support.
Yesterday Microsoft announced, among other things, that they would soon release a web-based version of their office suite, along the lines of Zoho Office and Google Docs. This announcement is a major step forward for the company and allows them to target users of other browsers and operating systems. As Micheal Arrington said, “Thank you Google” for kicking them in the shorts enough that they actually created a product that people want, rather than delivering a product and telling people this is what you get.
However, unless something changes Microsoft could still fumble the ball on this one through a confusing brand strategy for Office on the web. Currently, Microsoft has the following Office related websites/brands:
Add to that the new brand of “Office Web Applications” for these new web-based versions of the Office Applications. Also be sure not to confuse any of this with the Windows Live branded software and websites, and Mesh.com, which we will not even go into here. Personally, I think that Microsoft needs to pick a single overall brand for the web and create a consumer & business strategy around them. They started down this road with the original “Live” brand, but they have bobbled it terribly and managed to confuse most people that I have talked to. It looks like they will continue this trend with the release of these new products, which is upsetting because they look great, and should serve as a wake up call to Google to get their products out of beta and make some real improvements to them.
With all of the Macs being deployed in companies all over the world there are a lot of admins scratching their head on how to integrate Macs into a Windows world. The most common request these admins will get is, “Can you configure my Mac to get my Exchange 2007 email?”. The simple answer is, Yes. Regardless of whether or not you have configured, your Macs to authenticate against your Active Directory (which you should), you can configure Entourage to sync with your Exchange 2007 Server, to allow all of your Mac users to take advantage of your existing Exchange infrastructure. Use the howto below to configure your Entourage clients.
1. Give the account setup a useful name.
2. Enter the name and email address of the User for which you are configuring Entourage.
3. Enter of username of the user, enter the FQDN of the Active Directory domain name, and the password for the user.
4. Enter the public URL of your Outlook Web Access server. If you are using SSL to secure your OWA server as you should be make sure you specify that.
5. Enter the public URL of your Outlook Web Access server, with “/public” on the end. If you are using SSL to secure your OWA server as you should be make sure you specify that. This will allow your users to access your Public Folders.
6. Enter the internal FQDN of a domain controller in your Active Directory domain. This will be used to look up users from the Global Address Book.
7. Enter the Search Base for your Active Directory domain. This usually is just the internal DNS name for your NetBIOS domain name broken out into LDAP-centric format as displayed in the example.
These instructions will allow your Mac users to make full use of your Exchange Server. The one important note, is that your LDAP settings will be inaccessible outside of your LAN, as I do not recommend opening up port 389 on your firewal to allow LDAP traffic outside your LAN. This may prevent your Macs from making Global Address Book lookups when not connected to your LAN. What you may consider instead is setting up a VPN connection on the Mac to allow this to function fully.