Tag: Exchange

Posted on

The Experts Conference 2009 (TEC’09)

Earlier this year, I wrote about presenting at Connections’08 in this article. That went so well, I’ve also applied (and been accepted) to speak at another conference – The Experts Conference (TEC).

Up through 2008, TEC was known as DEC (the Directory Experts Conference) and it focused exclusively on Active Directory (AD) and Identity Management (IdM). It was definitely the conference to go to for gurus in AD and IdM and it has a huge representation from the Microsoft Directory Services Product Team.

Beginning in 2009, DEC is adding another track on Exchange Server. Originally, there was some discussion about running two separate conferences side-by-side: DEC and GEEC (Great Experts Exchange Conference), but eventually the decision was made to rename the conference and run two tracks: one on Directory Services and one on Exchange Server.

I am privileged to be one of the Exchange Server speakers at the inauguration of TEC. Originally presented by NetPro (for seven years) and now presented by Quest (who purchased NetPro in the second half of 2008), the conference is still being organized and hosted by Gil Kirkpatrick (a long-time Directory Services MVP).

The American presentation of the conference is in Las Vegas, NV; March 22 – 25, 2009. The European presentation of the conference is in Berlin, Germany; September 14 – 16, 2009.

For the American Exchange Server agenda, please click here.

For the bios of all the Exchange Server speakers (including me!), please click here.

For the abstracts of all the Exchange Server sessions, please click here.

It is the goal of TEC’2009 for the Exchange Server presentations to be as high quality and as technical as those they have always had for Directory Services. Thus, if you want in-depth Exchange Server knowledge from some true experts – TEC’2009 is the place to be. In tight economic times, you have to carefully pick and choose which conferences and technical events you want to attend. TEC’2009 should be your #1 choice. As you can see from the American agenda and biographies, there is a very strong representation from the Exchange Server product team as well as from the Directory Services product team.

I hope that you will join me at TEC’2009. It is a worthwhile investment for you and your company.

Until next time…

As always, if there are items you would like me to talk about, please drop me a line and let me know!

Follow me on twitter: @EssentialExch

Posted on

Exchange Connections – Fall 2008

Next week, in Las Vegas, Nevada is the semiannual Connections conference. The Connections conference is a technical conference covering SQL Connections, Windows Connections, Exchange Connections, etc. There are lots of individual tracks, both for IT Pros and Devs.

I’ll be speaking next week at the conference, delivering three Exchange presentations:

EXC10: Exchange 2007 and Windows 2008: Backups the Easy Way (75 minutes)
In this presentation I’ll show you how to use the native Windows tools present in Windows 2008 to make Exchange 2007 backups AND to restore them. I’ll cover some theory, some philosophy, and lots of PowerShell.

EXC11: SMB Exchange Operations (60 minutes)
In this presentation I’ll discuss so key factors of Exchange day-to-day operations that affect the Small Business

EXC12: Building an Exchange Test Environment in a Hurry (75 minutes)
In this presentation I’ll discuss some of ways in which you can quickly generate a virtualized Exchange test environment. After all, all the time you spend building, is less time you can spend testing.

You can see the Event Schedule here and general conference information here.

Please come say “hi”. Even better – attend my presentations!

Until next time…

As always, if there are items you would like me to talk about, please drop me a line and let me know!

Follow me on twitter: @EssentialExch

Posted on

Exchange 2003 Default Recipient Policy Problems with OMA/EAS

So, yes, I spend most of my time writing about Exchange 2007, but most of my clients are still on Exchange 2003.

I ran into an interesting problem today. It took me about an hour to figure out what was going on, but then it was a “duh, of course” moment on my part.

The real issue? Too many cooks in the kitchen. This problem was caused by a client administrator making a change I wasn’t aware of, just because he thought it made things “cleaner”. If I had been aware of the change before it happened, I would’ve said “no, that’s gonna hurt, don’t do it!” After the case, I would’ve said “let’s change it back.”

Anyway, the problem started with a report of a user who just got a Treo and couldn’t sync with EAS and couldn’t log into OMA. This is why:

When Exchange is first installed on a server, either Exchange 2000 or Exchange 2003, it creates something called ExIFS – the Exchange Installable File System. The purpose behind ExIFS is to allow an application to access Exchange mailboxes as if they were a file system – each folder representing a directory, each mail message or calendar item being a file, etc.

In Exchange 2000, this was visible by default, as the “M: Drive”. That caused huge numbers of heartaches. Many anti-virus solutions would scan M: and end up corrupting items. (Note that this was not necessarily the fault of the anti-virus vendors, as Microsoft guidance was quite clear about configuring the a/v solutions to NOT do this.)

In Exchange 2003, the M: drive was still present – but hidden. To access it, you must use a special syntax of NTFS, often called “the volume syntax”, as it can also be used to see your normal disk drives and mount-points, if you know their system names (which contain a 128-bit value known as a GUID). You access it by using this syntax \\.\BackOfficeStorage\. If you do a “dir \\.\BackOfficeStorage\” from a command prompt on an Exchange Server, another directory will be visible. This directory will be the DEFAULT SMTP domain in the Default Recipient Policy.

Now, when you first install Exchange, the default SMTP domain is the same as your Active Directory domain. So, if your Active Directory is named test.local, then your default SMTP domain is also test.local. As you create users with mailboxes, that Default Recipient Policy will stamp your users with test.local as their primary SMTP domain.

That is generally not what they want. J Most people have a different Internet domain than their AD domain. To solve this, you have two options:

1] Change the default policy, or
2] Create a newer, higher priority policy.

Option [2] is the correct choice.

If you choose option [1], then you will change the default SMTP domain. OMA and EAS depend on the default SMTP domain, and they were setup when you installed Exchange. Now, if you change the default policy, and leave it so that the default policy still generates the original email address, just not as the primary, OMA and EAS will still work. If you change the default policy and eliminate the original email address, then users created without that original email address will not be able to use OMA and EAS.

This is especially critical in SBS 2003 servers and in servers where KB 817379 has been applied (which has automatically been done on all SBS 2003 servers).

This is because the directory gets updated in the Exchange virtual directory of the Default Web Site automatically by the DS2MB process of Exchange’s System Attendant. However, the Exchange-OMA directory is not updated.

If you run into this problem, you can update the Exchange-OMA virtual directory, you can update the Default Policy, or you can update individual users with the other email address; whichever works out best for your organization or your security standards.

This problem disappears on Exchange 2007, since it no longer has OMA or the ExIFS. EAS on Exchange 2007 uses Exchange Web Services (EWS).

Until next time…

As always, if there are items you would like me to talk about, please drop me a line and let me know!

Follow me on twitter: @EssentialExch

Posted on

It’s All About The IOPS, Silly!

In yesterday’s EMO (Exchange Messaging Outlook eZine, subscribe at http://www.slipstick.com/emo) I had an article named It’s All About The IOPS, Silly! which discussed the impact of RAID-1 and RAID-5 arrays on total IOPS calculations.

However, space didn’t allow me to talk about SANs (Storage Area Networks) in regards to IOPS.

Where Exchange is concerned (and SQL Server as well, although that isn’t our focus here), you do not want to be sharing your “disk group” or “volume group” or “virtual array” (or whatever your SAN software calls it) with any other application – unless you’ve performance tested it in the worst case.

SANs allocate storage in terms of LUNs – Logical Unit Numbers. For a given server, a LUN is allocated to that server (note that in the case of clusters, quorum disk may be visible to multiple servers at one time) and only one server may have write access to that LUN at a time. A LUN may, or may not, be tied to a particular disk array or disk set contained within the physical hardware of the SAN.

Many types of SAN software support a concept known as “LUN Stacking”. In this case, an array (be it RAID-1, RAID-5, RAID-10, whatever) has multiple logical stripes of the disk where multiple LUNs are allocated on the same array. Arguably, this is what SANs are all about – allowing you to control storage logically instead of drive-by-drive. And, for many (perhaps most) applications this makes sense.

However, while the BEST CASE SCENARIO says that the IOPS available for a LUN is the maximum IOPS available for that disk set, the WORST CASE scenario says that the IOPS available for a LUN is equal to the number of accessors (servers) that are using that physical array.

So, for example, if you have five servers hitting a RAID-1 array via different LUNS, the best case performance scenario says that you can have the maxiumum IOPS available to the hardware available to each server. The worst case is IOPS / 5.

For example, if your RAID-1 group has a calculated IOPS of 250, one server could potentially benefit from having a total IOPS of 250 available to it. However, if all the servers are hitting the disk, the performance would be more like 50 IOPS. While for many small and medium businesses, an IOPS of 250 is probably sufficient to meet their Exchange needs – only the smallest of companies can get adequate performance on 50 IOPS total.

Another reason you want to avoid sharing LUNs is due to the usage profiles of the various Exchange needs.

Database access (which includes queues, mailbox stores, and public folder stores) is completely random. The creation of log files (transaction log files, message tracking logfiles, and protocol log files) is completely sequential. If you share LUNs between different usage profiles, then your performance will suffer (especially for those needs which are optimized for sequential access).

Conclusion: Just Say No! Don’t let your SAN guys tell you what kind of storage performance requirements Exchange has. You need to be prepared to tell them!

Until next time…

As always, if there are items you would like me to talk about, please drop me a line and let me know!

Follow me on twitter: @EssentialExch