Letting go doesn’t mean giving up… it means moving on. It is one of the hardest things a person can do. Starting at birth, we grasp on to anything we can get our hands on, and hold on as if we will cease to exist when we let go. We feel that letting go is giving up, quitting, and that as we all know is cowardly. But as we grow older we are forced to change our way of thinking. We are forced to realize that letting go means accepting things that cannot be. It means maturing and moving on, no matter how hard you have to fight yourself to do so.”

– Anonymous

Well over 3 years ago, I started BeingExchanged, and for several years before that (starting around 1998), I wrote articles and posts on Exchange Server. I was a hands-on Exchange engineer, working with that platform day in and day out, and enjoying every second of it.

Today, I am officially ending the BeingExchanged blog. It is a heartbreak that I find myself simply not working with Exchange Server enough to justify holding myself up as an expert in the field anymore. While I would love to write entries for the group of loyal and wonderful readers that come here every week, I find myself simply re-hashing stories that are already well publicized and published.

It was not an easy decision. I enjoy writing, especially blogging, and Exchange Server will always have a very special place in my heart. I still work with Exchange Servers on occasion, and enjoy it immensely when I do. But things change, and my career path has changed quite dramatically in the last 10 years. My work, and my knowledge, has grown beyond a single application, and I’m grateful that I’ve had the ability to work with so many aspects of Information Technology.

So, I’m still writing and blogging. You can find my work – among other places – right here:

http://www.newbie2mac.com

http://www.sociallyworking.com

http://www.newbie2virtual.com

I want to take a moment to thank everyone who has helped me with this blog over the years. The scores of Twitter followers who got the word out and contributed ideas; the folks at Microsoft who answered questions; and the users who got insight and help from my blog will all stay with me forever.

This blog will stay up for reference purposes, and of course I’m happy to offer any advice I can to folks who work on Exchange. I still read your blogs, your emails and your books, and that will not change.

So, to all of you who read and enjoy my blog, thank you. I couldn’t have gotten this far without you, and I won’t be able to continue unless you are there.



With warmest regards:
Mike “Talon” DeNapoli
Editor, The BeingExchanged Blog
miketalon@beingexchanged.com

Photo Credit: gogoloopie on flickr

Specifically they’re limited to 16 database copies per DAG group, no matter how many nodes you have or how much server power you have at your disposal.

Many folks have asked if this was an arbitrary number, or if Exchange itself has some kind of limit on how many database copies it can track. The short answer is none of the above, it’s based on the limits of Windows itself. How Exchange Works has the story here.

The basic idea is that Windows Failover Clustering in Windows Server 2008 can only manage 16 nodes within a single cluster. Since – in theory – all DAG database copies for a single database could be spread out so they are one-per-node, this limited the total number of DAG-enabled database copies to 16.

This doesn’t mean you are limited to 16 databases on a DAG, that’s actually limited by the version of Exchange Server 2010 you’re using.

For Exchange Server 2010 Standard, you can have up to 5 database instances. In Exchange Server 2010 Enterprise, that limit is 100. Note that this isn’t the maximum amount of active databases, it’s the limit on the total number of active databases and passive copies.

So on Standard, you can have up to 2 active databases in a DAG, since having 3 would mean 6 total (active + passive) and go over the limit.

Even with 100 possible instances in Enterprise, you can still have only 1 active and up to 15 passive copies of each database, so there are indeed still limits that fall well below 100 total.

Also remember that none of this takes into account Public Folder Databases, which – while still supported with their own replication engine – cannot leverage DAG at all. They’ll still count against your total number of databases for Exchange Server within any given DAG configuration.

Most of us won’t hit the 100 database limit, but for large organizations, the 16 database copy limit might be a boundary you need to be aware of when planning out your Exchange implementation.

Photo Credit: Louis K. on flickr

Since I make my living writing words about how to manage the words that flow through the Exchange Server platforms, it’s nice to take time out now and then to help other people find out about the power of words. And, as you probably guessed, I get to do it again today.

The Uprise Books Project got kicked off this week on Kickstarter, and everyone should have a look at it. The goal is simple, bring books that are (or have been) banned or challenged to everyone in the US under 18 who can’t afford them alone. So many school districts and communities can barely afford to keep schools open, much less pay for and keep stocked libraries in and out of those schools.

It’s hard enough for kids in many communities to find any books at all, much less books that have been traditionally – and sometimes sensationally – shunned by the mainstream.

So, why should you care? I mean, after all, these are BANNED books we’re talking about right?

Not exactly.

Many books of extreme historical import were banned at one time, and now they’re part of our daily lives. Uprise wants to make them part of EVERYONES’ lives.

Don’t believe me? Well, I’m sure you’ve read at least a few of these:

Huckleberry Finn (Mark Twain)



The Diary of Anne Frank (Anne Frank)


Brave New World (Aldous Huxley)



The Color Purple (Alice Walker)



Catcher in the Rye (J.D. Salinger)


Atlas Shrugged (Ayn Rand)


Fahrenheit 451 (Ray Bradbury)


Light in the Attic (Shell Silverstein)

And that’s just a remarkably short list of the thousands that have been banned or challenged over time.

Every one of us has felt an impact on our lives from at least one of these banned books (what, you never read Shell Silverstein when you were a kid?). Every kid today deserves to have their own experiences with them, and now you can help.

Visit the The Uprise Books Project on Kickstarter and ratchet open your wallet, purse or pocket. Everything is run through Amazon Payments (so you’re not handing your credit card to someone unknown) and the project is being run by a great bunch of folks – some of whom I’ve known via Twitter and other places for quite a while now.

The premise is simple, they’re building a website that kids can go to and select books from. Kids from 13 to 18 who meet certain income requirements can ask for any book from the catalog, and – if it is at all possible to get it for them – they get a new copy of the book to read.

The *premise* is simple, the application is going to be much more complicated. They need to build the website and get the books; and of course get all the shipping and tracking set up.

The benefits? First the kids get the books. That would be enough of a reason to become part of the project, but they’re going to do one better.

You will be able to choose demographics, topics and even specific books that you want to sponsor. These books made some impact on your life, now you can pass them on.

This is a great example of “Think globally, act locally.” The internet is our community, and supporting this project to reach their goal will help shape the minds of the kids who are going to go on to change the world.

Make a donation, kick in to a great project, and change the life of someone out there. Your teachers and parents did it for you, it’s time to repay the favor for communities that can’t do it for their own kids.

Photo credit: Mendhak on Flickr

MSFT released a KB article about the end-of-support-lifecycle policy for Exchange 2010 RTM. That last bit is the important part. RTM (Release To Manufacturing) is the industry term for the first version of a software package to roll out of the coding factory. The suffix is used to denote that there is no service pack applied, and that’s the key thing here. MSFT is ending support only for the non-service-packed versions of Exchange 2010, not for the entire product line.

As long you are on at least Exchange 2010 SP1, you’re still well within support, and have nothing to worry about. If you’re not on at least SP1, why not? There were tons of bug fixes, patches and security updates that were in the service packs, and you’re missing out on all of them! As next month, you’ll also be missing out on being able to ask Microsoft for help, so there’s another incentive for you to upgrade.

What about net-new installations? After all, if you go to install from scratch, won’t you be on the non-supported version? Not really. If you need to do a net-new installation of Exchange 2010, download the current version from Microsoft, or request media for it to be shipped to you. Since Exchange 2007, the Service Pack version of Exchange includes all binaries, not just the updated ones. So, you can easily do a net-new installation of Exchange that’s already updated during the install itself.

At any rate, while this is a bit sooner than normal, end of support lifecycle for products is pretty normal for Microsoft, but they never ditch the earlier version until at least 1 updated version is available. This allows them to keep supporting the application without supporting outdated or depreciated code, making life easier for everyone. So get out there and update to SP1, before you find yourself out of luck when you call MSFT for help after October 11, 2011.

First things first, we tried to see where the users were. Mostly they were in Europe and Asia. Normally that’s not a problem, but with a SHA-512 ID signature, there was a chance that it was some form of security export treaty keeping overseas versions of Outlook from unwrapping any message sent with that level of security. I was only signing, not encrypting, so normally this would only result in a garbled line of text instead of an actual ID seal, but I could see how it could cause the client to not render any text at all.

Then I got a reply back from one of my co-workers in China, and he had no issues reading the signed email at all. Great, that’s one theory shot.

Then we looked at the clients themselves. Both internal and external recipients who could not read the messages were all on Outlook 2003. All those who got email from me and had no issues were either on OWA, Outlook 2007 or 2010, or using a non-MSFT mail client. That was a killer piece of info.

After some web searches that went nowhere, one of my colleagues – who was still working on the “non-US security level” theory – suggested switching Outlook to force the signature to SHA-1, which he knew to be exportable for sure.

Viola! The emails were now readable in all clients. Interestingly enough, the default hash for Outlook 2010 and 2011 is SHA-512, which is based on SHA-2 technology; and Outlook 2003 just couldn’t deal with it. Once I switched to SHA-1, which was identifiable by Outlook 2003, everything was plain as day to those who got my signed emails.

So, word of caution, if you are going to use a Digital ID signature for Exchange email (of if your recipients might be using Exchange), make sure to use SHA-1 if there is any chance they might be on Outlook 2003. While it’s not as secure, it is readable, until we finally remove Outlook 2003 out of the ecosystem completely. Based on previous examples of how long email clients stick around, you should be able to safely go to SHA-512 sometime around the year 2260.

It’s by no means a complete consulting services tool, you just get the basic information necessary to plan out the new platform. It does, however, help with modeling out some of the rough design points like if you could get away with a combined role server, if you can leverage aspects of various roles in tandem, if you have the right type of platform for DAG, etc.

Now, in addition to the various local roles, you can evaluate your environment for potentially using Office 365 only, with no local Exchange Server installs at all. This is a pretty bold move for a company that used to make their big bucks with large in-house Exchange Server implementations. Encouraging smaller businesses to move to O365 makes sense, as the incremental revenue from new Exchange Licensing wasn’t near what they’ll bring in with monthly recurring fees for the cloud-based services. But by making the evaluations easier, they risk larger companies that could go cloud but until now didn’t know it finding out how easy it’ll be.

What will come next is anyone’s guess, but MSFT is definitely putting a lot of push behind the Office 365 offering. It’s interesting to see that they’re backing it up with active tools and not just a marketing effort, now we just need to see where the combined efforts lead.

So what is the problem?

The IE9 browser has a bit of a hiccup when it comes to some procedure calls that worked perfectly well in earlier versions of Internet Explorer. Since the Exchange 2010 Management Console is tied to the browser for rendering and such, attempting to use the console on machines that have IE9 installed invokes those procedures and therefore generates the errors. Basically, if you try to close the console, you’ll get a message that you need to close all child windows, even if none are currently open.

How do you fix it?

There’s a couple of ways. The most blatant and easiest is to just leave the Exchange Management Console open all the time. It won’t hurt anything, and the problem is very effectively solved. However, this can be a security risk, and so isn’t the best solution for environments with multiple Administrators.

You could also manually kill the process through Task Manager. That has its own issues in that you’re unexpectedly terminating a program thread.

You can also configure a server or VM with only IE8 installed on it. That would solve the problem, but you’d have to be careful about malware and staying on top of security updates (which you should be doing anyway) and not allowing automatic updates (which you may be doing now).

When will it get fixed?

Who knows. MSFT has promised something in the Q4 IE update, so hopefully the answer is “soon,” but there’s no guarantee here. Since the groups in Redmond so rarely talk to each other, stuff like this usually becomes an ongoing headache, so hang in there, this could be a rough one.

There are several reasons why you might not want to virtualize some components of the Exchange Server 2010 system, but among the top ones against it are resource contention and lower VM density.

Resource contention is a constant issue for shops that virtualize a large amount of their infrastructure. Multiple virtual machines (VMs) that run on the same physical host can be oversubscribed to resources like RAM, which is fine as long as they don’t all try to use their maximum RAM at once. Exchange Server has a bad track record with this, as it will try to use all the system resources it can get its core processes on, and never let them go. Exchange 2010 has made some great strides in this area, but it’s still a resource hog; and you want it to be. Faster Exchange processes mean less lag for your end-users and for your email flow in general. Fighting for resources with other VMs can cause queues to build up and mail to slow down.

Secondly, since Exchange 2010 has specific requirements for what processors and RAM numbers it needs dedicated to it, this will put a major crimp in your VM density numbers. VM density is the number of VMs you have per host machine, with the goal to make the number as high as possible. Exchange Server Mailbox Role, Microsoft SQL server and other high-load applications on a VM host mean that you have less physical hardware you can share among the other VMs, lowering the overall density of your VM hosts, and defeating the purpose of virtualization by forcing you to add more physical hosts, sooner.

Now, this isn’t to say that you can’t virtualize with Exchange Server effectively. Hub/Transport and CAS servers for Exchange 2010 are great candidates for virtualization. Load can be spread across multiple physical hosts in your production environment to give you multi-pathing ability. You can also virtualize Edge Services quite effectively, since you can isolate the Edge servers to a DMZ virtual network without dedicating physical hardware to that purpose.

However, heavily used Hub/Transport servers and most Mailbox servers should probably be dedicated to physical devices. The I/O overhead of a Mailbox server will be hampered by the shared I/O interfaces of the virtual systems, reducing the gains you get with the new Exchange 2010 storage structures. So it becomes a choice between high-end disk for VM data stores to keep up with the overall load, or lower-end disk on dedicated physical hardware. Disk is cheap, but not free (and SAN disk isn’t all that cheap), so it pays to pay attention to this.

Hub/Transport servers handle a lot more data overhead on physical devices, which is vital if you’re not going to put multiple H/T servers on multiple VM hosts to spread out that load. Here, it’s a trade-off between managing multiple virtual devices, or one physical device. A much more complex choice than with the Mailbox Role, but one that bears some attention.

Virtualization of Exchange 2010 is supported, and is a great idea for some of the roles of the overall Exchange 2010 eco-system. However, before you virtualize everything, take a long, hard look at what the trade-offs might be; and plan accordingly.

In Exchange 2007, Microsoft labeled downloads to clearly show that the Service Pack contained the entire software package. This was done by calling the downloads “Exchange 2007 with SP1,” and made it clear that you only needed to install the SP version of the binaries. Prior to this point you had to install the base version first – even if you were installing a net-new server that would never run in production with the non-Service Packed-version for more than the amount of time required to run the SP installer. You also had to install each Service Pack until you got to the one you were going to run with in production. (Editor’s Note: Yes, I know this wasn’t a strict requirement, but it was the safer path.) With 2007, you just prepped a Windows server and then ran the installer right from the SP binaries, which installed all the “base” code along with the updates.

As you can see on MSFT’s download page for Exchange 2010 SP1, the filenames have reverted back to the “Exchange2010-SP1-x64.exe” naming convention of just saying that this is the SP binary set. However, buried in the print at the bottom of the page, we see this:

“This Exchange Server 2010 SP1 software may be used to perform a new installation or to update an existing Exchange Server 2010 installation to Service Pack 1 (SP1) level.”

So, you can indeed simply install the SP1 bits onto a net-new machine, and be assured that you will have the whole package installed, not just the SP.

MSFT did make it clear that – going forward from Exchange 2007 SP1 – they would be including all base code in the SP binaries, but the change in the naming conventions for the downloads has confused quite a few people – myself included. Just goes to show that you should read the entire page before downloading. If for no other reason, then because you may find that you need to download much less than you though you did!

• PST files are not supported when housed on a file server. You have to store them on the device that is opening them, so either the desktop or laptop. This menus that data is probably not getting backed up properly, and you stand at a risk of data loss. You could put them on the file servers anyway, but then if you need help, you can find yourself out of luck.




• PST files have been depreciated from Outlook, and most tools have been removed from Exchange Server. In Exchange/Outlook 2010, PST files are not something you can easily manage. The Server has some tools to deal with them, but they were included in the software mainly to allow import of PST files into the database, not to actively manage PST files for users. Outlook requires manual operations to even create a PST, as the default configuration is to use Cached Mode (which uses a different local file format).



• They are locked to the desktop. You cannot open a PST that’s sitting on your desktop when you’re on the road. Outlook Web App can’t use them at all, so they are limited to local-storage only. With a highly mobile workforce, this throws a ball and chain around your employees’ legs.



• They’re becoming unnecessary. I’m not saying you will never find a need for a PST file – which is why Outlook still tolerates them, even if it doesn’t make life easy for them. However, the major reasons that folks used PSTs are now obsolete.
  
  
  
  • Storage space: Disk is not free, but it can be cheap. Exchange 2010 can use much less expensive disk than its predecessors.
  
  
  • I/O overhead: Exchange 2010 is designed from the ground up (and delivered on that design) to be able to handle many more concurrent connections than earlier versions without bogging down the client interface.
    
  • 
    Archiving: Exchange 2010 has native support for archiving, and there are a wealth of 3rd-party products that can extend that functionality. As an added note, data in PSTs must be tracked down during auditing and legal holds. Having all the data on the server itself makes that process a lot more secure (not to mention easier).
  
  
  
  
  
• PST files are insecure. Security is a major issue for all sized firms these days, and having PST files running around means you have data you cannot put your hands on. Employees can destroy them, either accidentally or maliciously, and external attackers can steal them. Granted, all of this can happen with OST files (the Cached Mode offline copy), but at least you still have the copy of the data on the server if an OST is compromised.

So, when you’re moving up to your next version of Exchange Server, take a good hard look at your PST architecture. Do you really need them anymore? Do you want them anymore? Can you survive without them from here on out (knowing that Cached Mode will allow offline access)? It may just be time to finally get them off your laptops and desktops and into the Exchange database, where that data belongs.