Friday, August 29, 2008
#
You may have missed this interesting blog post this morning amidst all the political kerfuffle, so let me sum up: the next version of OCS will only support x64 platforms.
This isn't the big deal it would have been for OCS 2007. A lot of the initial FUD around the 64-bit-only move in Exchange 2007 turned out to be mere steam. While there were some initial challenges involved in managing the new 64-bit Exchange deployment from 32-bit machines, Microsoft got a lot of the licensing figured out and released the appropriate sets of tools to allow management of Exchange 2007 from both 32-bit and 64-bit environments. I fully expect that the OCS group has been paying close attention to all of this and taken good notes.
There's no denying that Exchange 2007 benefits from the "64-bit only in production" stance -- and with the release of Windows Server 2008 and Hyper-V, not to mention Microsoft's updated support statement for virtualization environments, the need for 32-bit environments is going away. My biggest reason for wanting 32-bit Exchange environments was so I could run demos under Virtual Server; now that I have Hyper-V, I'm probably not in any rush to go back to Virtual Server and the 32-bit limitation. 64-bit hardware is the norm today, and the x64 Windows variants are solid and mainstream enough for my dedicated application servers. (Maybe not so for the desktop quite yet, but still getting there rapidly.)
The one thing I'm skeptical about, though, is whether the move to 64-bits is really going to reduce the total number of servers in the deployment. In Exchange 2007, I only saw the server reductions in very large environments; the mailbox-per-server gains we got from 64-bits was offset by the explicit breakout of roles and the business needs that drove redundant configurations like CCR (which meant no co-locating roles with the Mailbox role) and multiple HT/CAS servers. I'm wondering how this is going to play out with the next version of OCS, where it already has so many distinct roles in play.
What I *hope* to see is that the maximum capacity of each server role (such as the number of users per pool or the number of streams per mediation server) can be driven upwards; this makes the large datacenter configuration options much more attractive, because it does translate to a reduced number of servers. However, for organizations that still have relatively low bandwidth separating their various locations, 64-bits won't do much to help; OCS deployment planning is very dependent on bandwidth, and is often the top limit on scalability long before the limits of the 32-bit Windows environment.
Thursday, August 14, 2008
#
There are a lot of people out there who want to try to get around Microsoft's recommended configuration for the OCS Edge Server roles. For whatever reason, they don't like the thought of have two network interfaces, one on a publicly routable IP network, the other on the private network. I've talked in the past about some of the reasons why this configuration is not only recommended, but actually a good idea, but let's just say it took a lot of talking and thinking before I accepted that notion.
MVP Jeff Schertz has done a fantastic job of walking through the various permutations people have come up with, separating what will work from what won't, and explaining the pros and cons of each variant. I highly recommend this post.
I also want to amplify a point he makes: having multiple interfaces (whether physical or virtual) on the same subnet will cause interesting and otherwise inexplicable weirdness on a Windows machine. I'll write up the situation I'm seeing in a bit (not OCS!), but let me be clear: it's caused me all sorts of problems. Run, do not walk, away from any "solution" that requires this.
Monday, July 28, 2008
#
Continuing from my previous post on MOS...
I didn't really mention this in the previous post, but MOS is designed to provide a hosted alternative to the server-side applications. One of the goals is to continue working with existing native clients and client access methods, so (for example) you can access your Exchange Online mailbox through OWA (running from MOS), through Outlook, or even through EAS/Windows Mobile. In order to do this, though, your client applications need to know how to talk to MOS and provide the proper credentials.
You can do this the hard way or the easy way. The hard way is running around and reconfiguring each application by hand and teaching your users how to use a separate set of credentials. The easy way is to use the MOS Sign-In tool, a little .NET 3.0 application that runs on the client desktop. It interacts with Outlook 2007 RTM/SP1, LiveMeeting 8, and IE7+.
When this application is run, it will invite the user to logon to MOS. The first time they do so, they're required to change their password. It then detects the apporpriate applications, offers to configure them to work with MOS, and then just sits quietly on the desktop, providing a seamless SSO experience.
To be continued...
I'm at an airlift here in Redmond for the new Microsoft Online Services (MOS), Microsoft's hosted services platform. Right now, MOS offers a combination of hosted Exchange (OWA, Outlook, and even EAS!), hosted SharePoint, and Live Meeting. We've just gone through an overview of the service, and it looks cool -- enough so that I'm now seriously considering switching my personal domains over to it (especially since they offer the ability to synchronize with your Active Directory deployment).
MOS is currently in beta and you can go sign up for a time-limited trial. There's only a certain number of trial accounts active at any given time, so your trial request may not be provisioned immediately; however, you can go to https://mocp.microsoftonline.com and sign up for one. You'll need a Windows Live account.
As you might imagine, MOS allows you to associate one or more DNS domains with your online account. When you register for your account, you're asked for a domain. This domain is not verified and, in fact, seems to be used simply as an internal administrative tag -- once your account and service is set up, you have to specifically add DNS domains. Adding them is a fairly simple process:
- Register your domain name with a registrar.
- Provision your domain with a DNS provider (often combined with step 1).
- Add the domain name to your MOS Admin Center.
- Run the verification wizard and add the auto-generated CNAME to your domain's DNS zone.
- Validate the domain in the MOS Admin Center.
- Start provisioning users with this domain, enable inbound e-mail on this domain, etc.
The verfication step is an important piece, because this helps MOS make sure that you're using a domain you're actually in control of. Otherwise, malicious people could sign in and hijack your domain, which would suck. The way Microsoft does this is actually simple and elegant: they generate a unique CNAME record (that looks very much like a GUID), and ask you to add this CNAME record, pointing back to a server under their control, to your zone. This has lots of advantages:
- It's pragmatic. If you can add a CNAME record to a zone file, you effectively control the domain.
- It avoids the nastiness that can result in WHOIS-based verification and allows people who register domains to continue using proxy companies, hiding their personal info from WHOIS spammers.
- It's relatively easy. You simply have to add a simple record to your DNS; if you can't do this (or your DNS hoster can't do it for you), then you have much bigger problems managing your DNS and verifying your DNS domain under MOS is the least of your problems.
- It's low-impact. The generated CNAME is highly unlikely to be queried during normal operations by your users; only MOS is likely to be looking for it. It doesn't require you to repoint your MX records or otherwise make major modifications to your infrastructure if all you want to do is start using online SharePoint and Live Meeting.
Note that just because you add a domain to MOS doesn't mean you have to use it for email! That's a separate operation, which is a two-step process of enabling inbound email for that domain and then updating your MX records appropriately.
More on other MOS functionality coming later...big thanks to the event staff for their kind permission for me to blog!
Wednesday, July 09, 2008
#
While I was away on vacation last week, Microsoft finally released the DPM 2007 Rollup packages to Microsoft Downloads. (I blame Jason Buffington; I'm sure he waited until I was out of office.) There are both x86 and x64 packages; both require you to download three separate files.
In addition to various bug fixes, this rollup (also known as a "feature pack") provides the following new functionality:
- Official support for protecting Windows Server 2008 servers (and supported applications, such as Exchange Server 2007, running on Windows 2008), including protecting the system state.
- You get support for backing up clustered Virtual Server 2005 R2 SP1 environments. Before, the cluster itself was not seen as a cluster by DPM, and depending on your configuration you may have needed to do some funky scripting.
- Better tape handling. You can now share tape libraries between multiple DPM servers, reducing the cost of long-term tape retention and allowing better utilization of high-end tape libraries. You can also put multiple protection groups on a single tape; DPM 2007 RTM would start a new tape as it began writing each protection group, even if the previous tape was not fully used. This could get expensive.
I haven't yet been able to confirm whether the cleaning tape bug Tim noted has been fixed in this update, but I suspect not.
Applying this update is a four-step process:
- Install the main DPM update (DataProtectionManager2007-KB949779.exe)on your DPM servers.
- Install the SQL Server update (SqlPrep-KB949779.msp) on the machine hosting the SQL Server database for DPM. In a default install, this is the same machine that is your DPM server.
- Update the agents on your protected servers to version 2.0.8107.0. You can push them out through the console or manually run the .msp update package on your protected machines (using any supported push mechanism). You will need to restart the protected machines for the new agent version to take effect.
- Update the DPM Management Shell update (DPMManagementShell2007-KB949779.msp) on all of your DPM management stations (including the DPM servers themselves).
Although the official instructions give the update steps in the previous order, I have run all three udpates on my lab DPM servers before updating the agents on my protected servers, and as long as Microsoft doesn't say that's not supported, that's the way I'd recommend doing it -- that way, all of your PowerShell tasks are using the updates even if you don't have all the protection agents pushed out yet.
Thursday, June 26, 2008
#
Everyone's being so coy in the Windows blogosphere today. "As you may have heard..." Heck with that; this is wicked cool. Hyper-V has Released To Manufacturing ... and is already available for download. As the link explains, it'll start coming down the Windows Update pipe July 8th. If you don't want your Windows Server 2008 machine to be updated yet, don't be blindly accepting updates.
Why wouldn't you want to get it first thing?
- You're running a previous version of Hyper-V. If so, be aware that upgrading your VMs is not automatic. It's not a horrible process, but it will take some time. You have to manually export each VM, remove the VMs from the server, upgrade the server, re-import the VMs, then update the Integration Services. The more VMs you have, the more time this will take.
- You're running some software that is not yet compatible with Hyper-V RTM but works with an earlier build. In this case, you want to wait until that software has a patch available.
I fit into both categories. I think I'm going to wait until I'm back from vacation to do it.
Oh, yes, just because Hyper-V is now RTM doesn't mean that you can go run to install Exchange 2007 on it in production. See Scott Schnoll's post for more info.
As IT professionals, we are more than often prone to fall to the perils of magical thinking. (I'm sure this is a side-effect of being human, which is a pesky and bothersome condition I will have to do something about one of these days.) Magical thinking in this context is when we have not internalized the intricacies of a problem and instead rely on formulas rather than true understanding to come up with solutions.
At one ISP I used to work at, we had a glorious reclaimed piece of technology, an Auspex NS-5500 file server. Every now and then on reboot, this old beast of a machine would fail to boot up; the cure was to open the cover over the drive cage and give it a good swift whack. We all assumed that this was because one of the drive connectors was a bit loose, but when our "magic" fix failed to work one night I discovered that it was in fact because one of the screws holding things in place was missing, allowing the drive bay to sag just a tiny bit. It was this tiny bit of sag that put just enough stress on the connector for drive 0. Had we actually opened the case up earlier, we'd have been able to solve the problem -- and prevent a year of whacking the server.
All too often, I see magical thinking in the field of security. Case in point: I recently heard about a gentleman who has a client that is requesting ETRN support be added back to Exchange 2007, either natively or through an add-on. They want to deploy the Edge role in their DMZ, have it queue up mail for the internal organization, and then have their Hub Transports (in the internal protected network) initiate a connection out to de-queue the messages using the ETRN SMTP extension. The reason they want this is that they've done due diligence and read some very thorough documents about computer network zones and have come to the conclusion that all network connections must be initiated from the most secure network. This, they say, removes the threat of malware taking over the Edge server in the DMZ and allowing an attacker to use it as a launching point to the protected network.
Now, the recommendation for connections to be initiated from a more secure network to a less secure network is a good general baseline to follow when it makes sense. However, it is not realistic in all cases (if we followed this to the letter, nobody would be able to receive e-mail from external senders except through random polling of Internet SMTP hosts, which is not at all scalable). This is doubly true if you don't understand how the underlying protocols work. Case in point: ETRN, defined by RFC 1985, "SMTP Service Extension for Remote Message Queue Starting". Quoting from section 3, "The Remote Queue Processing Declaration service extension" (emphasis added):
To save money, many small companies want to only maintain transient connections to their service providers. In addition, there are some situations where the client sites depend on their mail arriving quickly, so forcing the queues on the server belonging to their service provider may be more desirable than waiting for the retry timeout to occur.
Both of these situations could currently be fixed using the TURN command defined in [1], if it were not for a large security loophole in the TURN command. As it stands, the TURN command will reverse the direction of the SMTP connection and assume that the remote host is being honest about what its name is. The security loophole is that there is no documented stipulation for checking the authenticity of the remote host name, as given in the HELO or EHLO command. As such, most SMTP and ESMTP implementations do not implement the TURN command to avoid this security loophole.
This has been addressed in the design of the ETRN command. This extended turn command was written with the points in the first paragraph in mind, yet paying attention to the problems that currently exist with the TURN command. The security loophole is avoided by asking the server to start a new connection aimed at the specified client.
See the problem? ETRN was not designed to solve a security problem; it was designed to solve a financial problem back in days when always-on bandwidth was a lot more expensive and most ISPs metered traffic. It masquerades as solving a security problem only because it's designed to avoid a loophole in an insecure and exploitable feature. As a result, ETRN won't solve the problem these people want it to solve; all it does is tell the system in the DMZ to initiate a new connection to the Hub Transport servers. It doesn't reuse the existing connection initiated by the Hub Transport servers. They can't use a firewall rule to block outgoing access from the Edge to the Hub Transport and be safe, because they'll cut off all incoming traffic.
However, let us for a moment assume that it did work the way they wanted it to: my Hub Transport initiates an outbound SMTP session to the Edge. In this session, HT is the SMTP client, ET is the SMTP server. As soon as HT issues the ETRN command, they still have to swap roles -- HT is now using the SMTP server code paths, while the ET is using the SMTP client code paths. Any theoretical vulnerabilities that are in the HT SMTP implementation are still going to be there, still exposed to the message traffic about to be sent down the connection, still open to exploitation.
This is the magical thinking: firewalls and a DMZ will protect my traffic. This is not true; firewalls and networks zones are two components of a complete security plan. Neither firewalls nor network zones can protect legitimate traffic, nor are they designed to; they are designed to allow you to designate which traffic is legitimate. If you want to secure that traffic, you need to turn to other measures.
Monday, June 23, 2008
#
Things got hairy enough last week that I forgot to post, but my hosting provider got the problem sorted out and the website is back online.
Wednesday, June 18, 2008
#
If you've tried to get to masteringdpm.com in the past couple of days, you may have gotten a cryptic error message instead of a site with DPM goodness. I'm working with my hosting provider to get it put back up ASAP and will post again once it's back up.
While I was at the Tech-Ed NA IT Pro conference last week, Jason Buffington and I took the chance to invade the Tech-Ed Online fishbowl studio and record a quick Tech-Talk on using DPM. You can now view it online on the Tech-Ed IT Pro page and the Library page, or stream it directly. Now that Tech-Ed's over, maybe we'll both find the time to be on Xbox Live at the same time so we can continue our discussion in Call of Duty 4...
Tuesday, June 17, 2008
#
Just a quick shout-out to fellow 3Sharpie Mike Rand, who just posted his first post to the 3Sharp blog site last week. Mike's a super-smart developer here with mad SharePoint skills; I can't imagine why he hasn't blogged sooner than this, but I hope to see him posting more frequently! He's also pretty good at foosball.
To reinforce yesterday's post about Exchange Web Services (EWS), I wanted to draw your attention to the Exchange Developer Roadmap posted on May 22 2008 on the Exchange API-spotting blog.
There shouldn't really be any surprises here, but there were a couple of items I wanted to highlight. First:
Given this commitment to Web services and our goal of making Exchange Web Services the richest developer interface for Exchange... (emphasis added)
Next:
Here's a preview of some of the functionality that we plan to add to the next release of Exchange Web Services:
- Access to Folder Associated Items (FAI) and read/write access to user settings (Devin: this page in the MAPI reference indicates that FAIs are things like views and forms. I believe that this also fixes a known quirk of EWS that keeps you from creating Outlook-visible search folders that use certain property paths. I believe this also gives access to server-side rules, if they're not already accessible through a separate part of the API.)
- Management of Personal Distribution Lists (Devin: very cool.)
- Throttling capabilities that give Exchange administrators control over system resource consumption (Devin: this will be very nice for helping keep poorly written applications from taking down the Exchange servers.)
- A powerful and easy-to-use server-to-server authentication model to enable building portals and enterprise mash-ups (Devin: let's hope this can ease some of the pain of building Exchange-aware SharePoint sites, at least those that don't require direct access to private mailbox content.)
- An easy-to-use Microsoft .NET API that fully wraps the Web service calls, which makes Web service development even easier (Devin: I'll be interested in seeing how this stacks up against third-party offerings like the Independentsoft EWS client offering.)
Then they go on to list the APIs that will get removed (Exchange WebDAV, Store Events, CDO 3.0/CDOEx, and ExOLEDB) and moved to "extended support" (Exchange Server MAPI Client, CDO 1.2.1). Don't get too excited by the MAPI client -- it's not what you think:
Provides server applications a MAPI runtime for accessing Exchange.
Note: This is not the Outlook MAPI Client library that is included with Outlook.
and
Outlook's Exchange MAPI Store provider, available in the Outlook MAPI Client library can also be used to access an Exchange mailbox or public folder.
If you're going to start writing Exchange-aware applications, you should probably start looking at EWS first for future compatibility. If you're trying to support Exchange 2003 at the same time...good luck.
Monday, June 16, 2008
#
I just got word that Independentsoft has come out with a beta version of an EWS client API for the .NET Framework and .NET Compact Framework. I've not looked at it yet, but I'm particularly hopeful about having a good way to work with EWS from Windows Mobile devices.
Exchange Web Services (EWS), introduced in Exchange 2007 and enhanced in Exchange 2007 SP1, is Microsoft preferred interface for all future programmatic reach into the Exchange store. While EWS is a Web service, it can be pretty complicated to work with. Luckily, we've done some work with EWS here at 3Sharp; Paul's been presenting some developer training sessions on EWS in partnership with Microsoft. We've found that Inside Microsoft Exchange Server 2007 Web Services
has been a valuable reference on EWS.
One of the challenges for EWS development is that the schema and object model is pretty complex when compared with the typical Web service, enough so that you need to use special Visual Studio proxy classes when you use .NET to work with EWS. This, by the way, is very likely the cause of the compatibility issue I found between EWS and SharePoint Designer -- Designer's proxy classes aren't the EWS-aware ones.
Monday, June 09, 2008
#
The talented people at 3Sharp are one of the best reasons to work here. Our Platforms Group is just one piece of the pie here; we've got some top-tier development talent who can make SharePoint stand up and dance. Those guys down the hall have been working hard on a little surprise they like to call the Podcasting Kit for SharePoint, which Microsoft has just released on Codeplex as indicated in their press release. 3Sharpies John Peltonen, David Gerhardt, and Paul Robichaux are also blogging about it, so if you’re interested, check them out.
I've been hearing bits and pieces, but last week I got to sit down and take a good look at what they're doing. Wow. This is some cool stuff that is going to make sharing podcasts, video talks, and other knowledge sharing content a lot easier. I can't wait until I can start using it; I've already lined up some content that I can put up and I'm already thinking of some more I can do.
If you haven't seen me in person recently, you may not realize I'm a heretic. Yes, that's right -- I use an Apple 15" MacBook Pro with Vista as my laptop. It took some jiggling to get it all working -- an upgrade to Leopard (OS X 10.5) for the final release of BootCamp, an upgrade to Vista SP1, and finding a stable version of the Atheros wireless drivers -- but it's now reliable and fast.
There are some downsides to this particular laptop. It's only gives me 2GB of RAM, which means that I can't run a typical VM configuration (DC, DPM, Exchange) and still have enough power to run PowerPoint like I could under XP. The battery life is okay but not great; I run out on long flights.
I'm off to Tech-Ed this week, so I stopped by the Apple store in Bellevue Square Sunday to pick up a spare battery for the flight. I've had bad experiences at this store in the past; I don't give off the right vibe(or maybe I just look light a tightwad) and can't get seem to get the attention of the staff. I took a chance, though, and walked in the store.
This time, my customer service experience was great. I caught the eye of Associate 1; although he was busy with another customer, he called for help; I didn't even see him do it. A minute later, Associate 2 walks up to me. "I understand you're looking for a 15" MacBook Pro battery." Pleasantly shocked, I followed him over to the appropriate shelf and soon had the battery in hand. "Is there anything else I can help you with, or are you ready to check out?"
If you've not been into an Apple store recently, they're doing something absolutely sweet. Each customer service associate has a hip-mounted scanner/cardreader. They scan your merchandise on the spot, take and run your credit card, and ask you for an email address to send the receipt to. Boom -- it's all done, your card is charged, and you don't have to stand in line at the counter unless you're doing cash or check. This is a great concept I'd love to see other stores use. My receipt hit my Exchange account (and thus my Windows Mobile phone) as I was walking out of the store.
I love living in the future.
Wednesday, June 04, 2008
#
Just a quick note to let you all know that the Protecting Exchange Server with DPM 2007 white paper is available for download from Microsoft. This is the same white paper I worked on for them last year, but freshly revised to include more guidance around mailbox-level recovery.
I'll be giving a talk around this topic next week at Tech-Ed (IT Pro) in Orlando, session number MGT369. Hope to see you there! (Yes, this is the same talk I did at Exchange Connections in Orlando and in MMS in Vegas a month ago; it seems to be a popular session!)
Monday, June 02, 2008
#
This is pretty cool -- I didn't even notice this at first! Hyper-V RC1 is now available for download through the Microsoft Download center or through Windows Update as an optional update. One of the nice changes here is that you now install the Hyper-V Integration Services on Windows 2008 guest machines the same way as any other operating system (before, you'd have to install the Hyper-V patch itself as a separate action).
That would be why my Windows Server 2008 machine wanted an extra reboot this afternoon...
...so I'll throw in a fourth for good measure. Rather than try to write a full-length post about each of these, I'm just going to give you a quick bullet list:
Friday, May 09, 2008
#
A lot of you may have missed this: Microsoft just released a new white paper for Exchange,
Outlook Anywhere Scalability with Outlook 2007, Outlook 2003, and Exchange 2007. This paper should give you some detailed guidance goodness on scaling your CAS servers, and also talks about the port exhaustion issues that lead to upper scalability limits.
Devin talks about several Exchange certificate-related tidbits.
Tuesday, May 06, 2008
#
I've been sitting on a cool announcement for several days now, and I'm happy that it's now time to announce it.
I've been working with a group of people to get a new user group for Unified Communications (UC) put together here in the Pacific Northwest. While all of us are here in the Puget Sound area, our goal is to put in place a framework to empower a variety of events and meetings all throughout the region, not just based here in Seattle. Rather than be a typical boring user group with a jawbreaking acronym (PNWUCUG, which we do use), we're defining ourselves as people who do UC. This gives us a simpler name -- We do UC, hosted at ucdoers.org.
From our website:
We are the Pacific Northwest Unified Communications User Group (PNWUCUG) and we have a passion for UC. If you are one of the following, you could be one of us:
- IT professionals in the Pacific Northwest who design, deploy, or manage Exchange Server, Live Communications Server, and Office Communications Server systems.
- Developers who write or maintain solutions that integrate, extend, or provide UC capabilities to Exchange Server, Live Communications Server, and Office Communications Server and clients.
- Industry experts with a recognized expertise in UC.
- Hobbyists who are exploring Microsoft-based UC solutions.
One thing that's important for me to clarify -- my vision of this user group (which is echoed by the other folks who are getting it off the ground) is that it exists to support all Exchange, LCS, and OCS users, not just people running 2007 and doing the VoIP stuff. We may have a focus on UC, but that's mainly to align ourselves with the direction Microsoft is taking these products. If you're using Exchange, we want you to participate; we want to make sure we have content for you.
So, if this sounds like goodness to you, head on over to the blog for the announcement of our May 28th kick-off meeting at The Parlor Billiards & Spirits in Bellevue, WA. For those of you who can't be there in person, we're even going to have a Live Meeting feed for you -- how cool is that?
Friday, May 02, 2008
#
As I typically do, I'm posting links to my slide decks for the presentations I just finished giving. I apologize to the Connections folks; I was supposed to get this done Monday afternoon or Tuesday and got ambushed by a travel-induced migraine.
Orlando was nice this time of year; not too hot, so the humidity slipped under the radar. It was nice to see a bunch of familiar faces and meet some new ones, and I was very pleased with the attendance at all of my sessions. Doing all three sessions back-to-back is definitely a drain, but the conference organizers helped out a lot by keeping me in the same room for all of them, and had I stayed for a couple of days I'd definitely have had the . And I have apparently finally beaten my notorious string of demo failures; my demo DPM environment (provided by Jason Buffington of Microsoft, thank you Jason) worked quite nicely.
For the MMS folks, I can't put my deck up directly; you'll need to get it from the MMS CommNet or wait for your attendee DVD to show up. Las Vegas is still completely over the top; the Venetian was opulent and provided a nice venue. For some reason, the casino didn't seem nearly as intrusive as it could have been (and is in other venues). I am, however, glad I had new shoes -- my feet didn't hurt from all the walking. For the flight home, I picked up 21: Bringing Down the House - Movie Tie-In: The Inside Story of Six M.I.T. Students Who Took Vegas for Millions
at the airport and read it cover-to-cover; a great story told well.
This was a big travel week for me; I got the privilege of speaking about protecting Exchange with DPM 2007 at both Exchange Connections (in Orlando) and Microsoft Management Summit (in Las Vegas). The session had a good response at both shows, and there's clearly a lot of buzz going around about DPM. I've gotten some good questions which I'll list here and update as I get answers.
- Q: Does DPM protect message tracking logs on an Exchange mailbox server?
A: Very good question. My gut instinct is "No" but I need to confirm that. I'll post the confirmation in a separate blog article when I get an answer back.
- Q: Is there any good guidance on sizing a DPM installation?
A: Yes. First see the Data Protection Manager 2007 Storage Calculator (currently only supports the Exchange workload), then see this third-party deconstruction. Note that the second post was written against an earlier release of the calculator, so is in need of some updating, but it's still a good read.
- Q: What kind of overhead does DPM incur?
A: I have to admit that I don't remember the specifics of this question (this is why I strongly encourage folks to email their questions to me, as is the case with the following question -- thanks!); all I have is a cryptic note "CPU overhead" on my notepad. So, I'm going to assume that we're talking about the overhead of the protection agent on a protected server. And my answer to that is: Very good question; I need to get some specifics.
- Q: From e-mail: "Yesterday during MMS at the Advanced Exchange protection session you mentioned that you had created a white paper on getting DPM working with IBM’s TSM product. If you have a link to this I would be very grateful as I have not been able to find it currently and I am wanting to ensure that they way I have it set up and kind of working is the same way that someone else has been able to get it working."
A: Unfortunately, I must have been unclear, for which I apologize. 3Sharp did work with Microsoft during the DPM 2006 timeframe to create several white papers on how to integrate DPM with several backup products: Commvault QiNetix, Symantec Backup Exec, Yosemite Backup, and Windows Backup. Unfortunately, Tivoli wasn't one of them, and I'm not aware of any current guidance that gives a complete end-to-end picture of integrating TSM with DPM 2007. However, the Backup of DPM Servers section in the DPM Operations Guide should be a good starting place.
- Q: Why can't I use DPM 2007 to recover to the Recovery Storage Group on Exchange 2003 servers, only on Exchange 2007 servers?
A: Another great question, which I'm querying to find the answer to.
- Q: If I can use DPM 2007 to do document-level recovery in SharePoint, why can't I recover mailboxes or even messages in Exchange without having to use the RSG (for Exchange 2007)or ExMerge (for Exchange 2003)?
A: There are two parts of this answer, but they both are based on the same premise: DPM does not use "privileged" information on the internals of other Microsoft applications it protects. When recovering documents from a SharePoint replica, DPM doesn't directly reach into the replica database and extract the information. Instead, it recovers the relevant databases to a temporary recovery SharePoint installation (which can be a single server SPS 3.0 install on a virtual machine, even if you're recovering data from MOSS 2007) and then finds the relevant documents using SharePoint's HTTP interfaces. With Exchange, the principle is the same; we recover the mailbox database to a parallel location (the RSG in Exchange 2007; a network folder in Exchange 2003) and then use the Exchange native tools to extract and import the relevant information. Trying to do direct restores of mailboxes or messages into a production database would involve going beyond the existing Exchange APIs. Personally, as an Exchange MVP I hope that Microsoft works on expanding those interfaces to make this sort of thing easier for all third-party vendors, but until they do, DPM plays by Exchange's rules.
- Q: You mentioned coming updates to DPM. Where can I find more info on that?
A: Jason Buffington of Microsoft has you covered with this webcast.
That's a good start for now; catch you all later!
Monday, April 28, 2008
#
I'm posting from a break between sessions at Exchange Connections in Orlando, FL. I just had a good session on protecting Exchange with DPM -- thanks to everyone who attended and gave lots of good feedback.
Next up -- a session on DCAR with Exchange, and then Exchange 2007 update best practices.
The weather is actually the best I've ever seen here -- not too hot, with a nice breeze, so the humidity isn't overwhelming. However, the A/C is up full in the room I'm presenting, so I'm glad the speaker shirts are long-sleeved.
More later!
Wednesday, April 23, 2008
#
I was completely floored to discover, via Paul, that you can control which codec the UM role uses to record voicemails on a per-user basis. This is seriously cool stuff, and if you can't see why quite yet, let me offer the following scenarios for you:
- Most common: you have multiple users who have non-Windows Mobile devices that don't support the WMA codec, but still want to be able to listen to their voicemail on their devices. The GSM and G.711 PCM Linear codecs may be more widely supported. For example, on an EAS-aware iPhone will Apple also roll in support for recognizing UM voicemails? If they do, will they support the WMA codec? Now, in theory, they don't have to.
- Also common: you have multiple users who use a non-Windows based client. (Paul already calls out one example, those of us who use Entourage.) This would be just as valuable, though, for people who are using some IMAP or POP3 client on a Linux/BSD/Solaris box.
- Not so common, but possible: you have a specific need to automatically process voicemails in an automated fashion and need to use either the GSM or G.711 PCM linear codecs instead of being able to support WMA. Switching one or two mailboxes over keeps the entire Exchange storage system from suffering the increase in voicemail file size that would result.
Okay, so these are slightly lame scenarios, but I'm sure there's more out there that I can't see.