atom beingexchanged: October 2008

Wednesday, October 29, 2008

This post has nothing to do with Microsoft Exchange.

Sorry to take a brief break from the interesting stuff about Exchange Server, but I would like to take a moment to say something to my readers here in the United States.  This isn't to say that the international readers have to close the browser, just that this is aimed a bit closer to home than most of my posts =)

Recently, I've found quite a few people close to me who will not be voting on Tuesday (or before, or at all).  Not that they can't get to the polls, or that they're confused on the issues, or anything like that.  Just that they don't want either candidate for President to be in office.

I can get behind that sentiment, but not the end result.

There are more than two candidates running.  There is a blank spot where you can write in someone else, so please, think long and hard before you stay home.  Every citizen who is eligible to vote can change the future of this country - but only if you go to the polls.

There are elections for judges, Senators, local and Federal officials, propositions - you name it and it's probably on a ballot somewhere in this country.  So even if you feel you truly don't want to cast a vote for the next leader of this country, don't give up all of the other choices that are waiting for you in the voting booth.

Who you choose to vote for is entirely up to you, I will not influence that decision.  If you truly believe that you want no part in this, that you don't care who the next President, or Senator, or judge or official is, then by all means refuse to vote.  But please, even if it means voting against a candidate instead of for a candidate; please if you have any opinion at all, stand up and be counted.

This will be an unbelievably close election if *any* of the polls have it right.  The future of our country could literally be in your hands on Tuesday.  You will have to follow your heart and your values, but please be very sure you want to let this choice pass you by.

Please, this Tuesday, remember:

"The price good men pay for indifference to public affairs

is to be ruled by evil men."

- Plato

Bookmark and Share
posted by Mike Talon at 0 Comments

SharePoint vs. Public Folders

When Exchange 2007 released, Microsoft let it be known that Public Folders - long a standard part of Microsoft Exchange - would be "de-emphasized."  This is basically Microsoft's way of getting the band warmed up for a rendition of Kiss Him Goodbye, and a really good sign that it's time to move on, since Public Folders won't be around much longer.

Granted, Service Pack 1 brought back some of the administrative tools used to managed Public Folders, but a lot of the functionality just isn't in Exchange 2007, and will never be.  So, where does an organization turn for Public Folder-like functionality?  Microsoft Office SharePoint Services (MOSS) 2007 offers a way out.

SharePoint has come a long way since the days of Team Services.  The MOSS system can now handle all the Public-Folder system's responsibilities and do much more.  As with Public Folders; you can store shared contact lists, share calendars, trade files and generally make information objects available to anyone who you want, with explicit rules set by you for who can see and change what.  Unlike Public Folders, integration with Outlook is not quite so seamless when using MOSS, and you'll need to take that into consideration as you move toward the new platform.

Public Folders are natively part of Outlook, the end user just browses the tree and picks the folders they want to see. If they have the right permissions, the folders open - end of story.  MOSS must be integrated with Outlook manually, a solution set that requires steps both on the MOSS sub-site in question and in the Outlook client.  The functionality unleashed is much more than you can get with Public Folders (document libraries, wikis, interoperability with literally thousands of Microsoft and 3rd-party titles, etc), but many Outlook users - let's face it - can barely figure out how to get their email. 

It is worth the extra work, however.  Once SharePoint is configured within Outlook, the world of online and offline work, dynamic updates and of course the ability to check files in and out to avoid overwriting other people's changes are all a generation beyond the Public Folder technology.  Some of this function can be created within Public Folders, but they're all native to SharePoint solution sets.

Add in the fact that each week there are more new, solidly built, and widely varied application sets designed to extend MOSS so that it can do more things easier and faster.  There are database hooks, CRM extensions (both for Microsoft Dynamics CRM and 3rd-party solutions) and even systems that can help you create an entire intranets using a WYSIWYG interfaces.  The majority of these solutions simply won't work with Public Folders.

MOSS is slowly but surely assuming its place as the heir apparent to the Public Folder infrastructure present in most existing Exchange organizations.  Integration (with some steps) into both Outlook and Outlook Web Access, clients that run through Internet Explorer (which means Mac ready too) and the ability to create dynamic content without the site administrator being called in for every single update all make the system more flexible and extendible when compared to Public Folders.  MOSS also does all of this without requiring you remove Public Folders from the environment, so you can indeed allow the two tool-sets to co-exist as you move your user-base from one to the other.

Bookmark and Share
posted by Mike Talon at 0 Comments

Monday, October 20, 2008

Comments Welcome!

Whoops, yours truly forgot to turn on the comments feature for the blog (must be caducity* catching up with me).  Of course, I was wondering why the heck no one was leaving any, and all along you couldn't leave one if you wanted to.

Well, that's fixed, moderated comments are now allowed.  Please feel free to leave a comment, I promise to check and approve them at least once per day. You have to identify yourself to leave a comment, but you can do so using a login from any of the Blogger.com sites or use an OpenID login.

Of course, you can always contact me directly using the link over on the right-hand side of the page in the Links section.

Thanks for reading!

* Caducity (or succumbing to the problems of old age) is one of several dozen words that are in danger of being removed from future versions of dictionaries due to general disuse.  The NPR radio show "A Way With Words" asked columnists and authors to use some of these words more often.  Find out more here!

Bookmark and Share
posted by Mike Talon at 3 Comments

Get the message? If not, it may not be your fault.

Microsoft Exchange engineers have always come under fire when a message that was sent to someone in their organization didn't get delivered, for whatever the reason may be.  The same goes for messages that bounce back for no apparent reason.  It could be a problem with the user's account (disabled, misspelled, etc) or it could be a problem with the server (offline, not connected to the net, etc).  It could also be a problem totally outside your organization, and that's what I'd like to talk about today.

In this ever-more interconnected world, routing of email can often depend more on external factors than internal ones.  Email messages can get mis-routed or even totally lost well before they reach your system, or can get purposely removed from the Internet somewhere along the way through no fault of your own.  If you're finding that more and more outgoing email is lost without any visible reason, the most common problem that is beyond your immediate control is getting accidentally blacklisted.

Blacklists are specific shared lists of either email servers or - in some cases - individual email addresses that spam control companies make available to end-users.  The most common of these is the DNS BlackList (DNSBL) which can either track IP addresses of servers known (or thought to be known) to send spam, or can track the domain names of such servers.  You can find out more about DNS BlackLists from Wikipedia at this link.  These systems collect information on servers and domains that send out spam and/or dangerous files (like viruses), and share that information with anti-malware companies (like McAfee and Kaspersky among others).  The anti-malware companies then use those lists to update their anti-spam and anti-virus solutions to protect consumers.

So if your server's IP address or domain accidentally ends up on these lists, suddenly external servers won't send mail to your servers anymore and won't accept incoming mail from you either.  It isn't easy to get on these lists by accident, but it could happen to you.  One or more internal users may get hit with a virus that sends tons of spam mails out from your email server, or someone totally outside your sphere of influence gets their computer taken over by a virus that forges headers to make it look like your servers are sending spam - and that's just two examples of things that could get you accidentally listed.

Once you're on these lists, it can be a very time-consuming process to get yourself un-listed.  Generally speaking, it will be a manual process of contacting each organization that has you listed on their blacklist system, and proving that you don't deserve to be there.  You can start your search at w3dt.net, which will assist you in figuring out which companies and filters have got your IP listed as up to no good.  Once you have that information, contact those organizations directly and either ask what caused you to get blacklisted or - if you already know that info - what you've done to stop the problem.

Be prepared to show that you identified who was sending the spam and why (and that you stopped it), or that you've isolated and removed the virus.  You will need to be patient and persistent, and will probably need to make several calls over a significant period of time (days to even weeks) to make sure that the problem gets solved.  Each organization that has you blacklisted will want their own proof that you're not a threat anymore, and in reality - provided they're not abusing their power - I can understand why they're being so careful.  Spam and viruses are a huge problem in the net today, and making sure they protect their clients is their business model.

Once you have the blacklist fixed to show you're not a spammer anymore, it can still take several days or longer for end-users of those services to get the updates to their spam and virus control systems.  So, if you do end up on a blacklist, you have quite a road ahead of you, but well worth it to clear your good name!

Getting blacklisted accidentally is a horrible thing.  Blacklists are a good thing overall for the benefit of email users all over the world, but when they suddenly stop you from emailing anyone (or getting email yourself), they can be a giant headache that you'll have to deal with effectively to get back in business.

Labels: , , , ,

Bookmark and Share
posted by Mike Talon at 0 Comments

Monday, October 13, 2008

Exchange 2007 pre-req's

For those installing Exchange 2007 for the first time, you'll have to change the way you normally prepare a Windows 2003 server for Exchange 2003.  While that may sound like a blinding flash of the obvious - given all the changes in Exchange 2007 - an ounce of preparation can still make your life get a lot easier.

As mentioned in earlier posts, Exchange 2003 will not run on x64 hardware at all, so first things first, you'll need a fresh x64 server with Windows 2003 (preferably R2). [Note: these instructions are *not* correct for Server 2008, there is a great article on how to do that here] Once you get the base OS up and running, install IIS in "Application Server" configuration.  You can do this by going to Control Panel|Add/Remove Programs.  When the Add/Remove wizard starts, click Add/Remove Windows Components on the left-hand side of the window.  Internet Information Services will be one of the components you can install, but just using the "Application Server" profile will give you what Exchange 2007 needs.

Unlike with Exchange 2003, do NOT install SMTP or NNTP.  Putting either of those services in will lead to an error in 2007's pre-flight check, requiring that you go back and remove them.

Once IIS is in, upgrade the server to Service Pack 2, this will install most of the other pre-requisites you need, but not all of them.  You will still need to go to Windows Update after the SP2 install and pick up about 30 hot-fixes and patches.  Installing IIS before SP2 will allow the Service Pack installer to upgrade everything at once, instead of requesting that you shuffle disks in and out of the CD drive - which is what will happen if you Service Pack first, then install IIS afterward.

While hot-fixing, be sure to install .NET 1.1 and 2, and preferably 3 as well.  This will require several Windows Update runs, as each of those has service packs and hot-fixes you'll need to grab.  Since PowerShell and many components of Exchange 2007 will need these platforms, it is easier to install them at this point, as they show up in Windows Update as Optional Software, so you can grab them in a semi-automated manner.

Speaking of PowerShell, once you get all of your updates and .NET installs done, go ahead and download and install PowerShell.  You can get PowerShell 1.1 for x64 Windows 2003 from this link. 

By following these steps, you can pre-stage your Windows 2003 x64 system to be ready to run Mailbox, Hub/Transport and Client Access Server roles for Exchange 2007.  You should have no issues with the pre-flight check and install, with one notable exception.  If you are creating a multi-role (default) install, and you are using Exchange 2007 SP1 binaries - which you probably should be doing - then you'll get an error about not having an SMTP send connector to the Internet.  This is normal on a brand-new Exchange 2007 install, and can safely be ignored at that point.  But, if you plan on sending mail to the outside world, be sure to configure an SMTP connector after your install is done.  You can find out how to do so (and do a lot more with Hub/Transport roles) at this link.

Taking some time to pre-configure tools on your server prior to starting your Exchange 2007 installation will allow your install to go faster, and pre-empt annoying error messages about things being missing.  Since most of these steps (install SP2, Windows Update, etc) are Microsoft best practices anyway, they are a great way to kill two birds, with one very large stone.

Bookmark and Share
posted by Mike Talon at 0 Comments

Friday, October 10, 2008

Moving from 2000 to 2007? Heads-Up!

Microsoft recently released a KB article describing an issue that can stop a mailbox from properly transferring from Exchange 2000 to Exchange 2007 if they use a lot of Public Folders.  Of course, "a lot of Public Folders" is a relative term, but thankfully the KB does outline specifics.

If you're moving a user mailbox from Exchange 2000 Server to Exchange 2007 Server, and the user utilizes Public Folders on the 2000 server, and they have more than 819 Public Folder items read in their mailbox; then the mailbox move will fail. 

There is a patch, but since this is a specific issue only patch (where most Admins should not install it), it is only available from Microsoft directly.  You can find out more about the problem, and find out how to get the solution, via this link.

Happy migration!

Bookmark and Share
posted by Mike Talon at 0 Comments

Monday, October 6, 2008

Online Versus Offline Defragmentation

One of the more common questions I hear from my clients is "Would I ever need to run an offline defrag on my Exchange Databases?"  The answers do vary, but in the end, they all boil down to "yes, occasionally." This invariably leads to questions about why offline defrag is necessary when Exchange 2000/2003/2007 does online defragmentation on a regular basis.

Defragmentation in Exchange Server comes in two different forms, online and offline.  While both take steps to make Exchange run more smoothly, they are designed to do different things.  They are also designed to run at different times. Online defragmentation is performed during maintenance (usually nightly); while offline defragmentation is a manual process.

Online defragmentation is the process of compacting the database, so that white space is pushed to the tail-end of the EDB files.  White space is - simply put - empty pages within a database.  In the case of Exchange, white space is created when items are permanently deleted during deleted item retention cleanup, when pages are removed from the database due to normal operations, or any other time something within an EDB gets removed.  Since databases like Exchange don't really delete anything normally, what happens here is that the areas of the database/disk where objects are deleted are simply marked as empty.  These areas, however, still exist within the database file (and on disk), and can cause performance slowdowns as read and write operations have to happen over a larger area of physical disk, and the database system has to keep track of all the little white space pockets.

During a nightly (by default) maintenance run, in addition to cleaning up deleted items and performing other tasks, the Exchange system will identify all white space and move it to the end of the database.  Compacting like this allows the database to work much more efficiently, and allows the maximum amount of white space to be re-used for new data before the system must take up more of the empty disk space.

While this process does allow Exchange to more efficiently use white space, there are times when just moving stuff to the back of the database isn't quite enough. While offline defragmentation shouldn't be done routinely, it is a great tool to use when you:

1 - Need to remove a large amount of unused space from a database. This could be because a large amount of mail was removed all at once from a system - as would occur if an archiving solution were implemented.  Online defragmentation would remove the data, but leave a large amount of white space that may be taking up too much room on disk.  Note that this only applies if a *large* amount of white space exists.  Unless there was a huge amount of data removed, you would end up with the database growing to the same exact size as before the offline defrag, probably within a few weeks or less.

2 - Certain types of errors appear in the Exchange system.  See this link for specifics.  Offline defragmentation can correct for some common errors, fixing a database in the process.

3 - A "Mail Storm" impacts your server.  Mail Storms are large amounts of mail (several times your normal volume) suddenly moving across a server.  Since this can create a large amount of white space and badly fragment a database, running an offline defrag can correct for any negative effects of the Storm.  This is another instance where we're talking in terms very large numbers, as smaller storms (such as a sudden increase in normal spam) would not fragment the database enough to allow you to gain benefit from an offline process.

One thing to note, you will need a place to hold the temporary files created during the defragmentation in order for the process to work. Generally, Microsoft recommends about 110% of the size of the database you'll be defragmenting, which is often quite a large chunk of space. This can be on another local disk, or on the same volume as the database itself, space permitting.  While it is technically possible to use a remote or network drive for temporary space, it isn't recommended, since it slows down the process and will cause it to fault if the network link hiccups.

Offline defragmentation is not required to be run on any form of schedule, as a matter of fact Microsoft doesn't recommend running it at all unless there's a concrete reason to do so - such as those listed above and here. However, if those conditions are true, then an offline defrag can help make Exchange run better, use less space, and stay healthy for the long haul.

Bookmark and Share
posted by Mike Talon at 0 Comments

Friday, October 3, 2008

We closed the joint!

Another great ClusterFunk party has ended as the Double-Take crew (along with our CDW guests) partied at the House of Blues in Chicago until they closed the bar.  For those who never had the chance to see ClusterFunk, they're a band made up of several Double-Take employees - including our CEO - and various guests.  This time we had one of our repeat guest performers, Patrick from Microsoft on the fiddle!

Some images from the event:

Band01 Band02

And as I've said before, there are very few CEO's who rock out like this:

Dean01

Yes, they actually play their instruments, and everyone had a great time. 

I do try to keep this blog pretty neutral, but when you get to party as part of your job from time to time, you have to blog about it =)

Back to the Exchange stuff shortly...

Bookmark and Share
posted by Mike Talon at 0 Comments