Introducing the new ESE Consultants' Corner

Our writers consult on a daily basis, and constantly receive calls from either customers or colleagues asking about Exchange, Active Directory, Virtualization, Cloud computing, etc. Some of the questions they encounter are common, but others at times are very weird.

The ESE Consultants’ Corner is devoted to answering only the really cool questions our writers get asked on a daily basis. We will share with you their answers to the common questions and the not-so-common ones, so that you can benefit and learn from their expertise. The ESE Consultants’ Corner will be devoted to covering a broader range of topics as well as addressing questions that require fast answers.

We want to hear from you! Do you have an advanced technical question that you need answered? Do you have a design or planning issue that you want expert input on?

Please send your questions to: ese@enowinc.com. This will give you access to the ESE experts and allow you to ask them questions directly. If we encounter a really tricky question, then we might devote an article to it.

The rules for submission are simple:

• Send your questions to ese@enowinc.com.

• ENow will select the best questions and answer them in the next edition of the Constultant Corner.

We want you to have a say in the topics we discuss, so email us your questions today!

Before we begin the Consultants' Corner, please note Mahmoud's Magdy's updated OCS-DNS calculator below.

The key to a successful Office Communications Server Deployment: The Errata and new OCS-DNS Certificate Calculator

By: Mahmoud Magdy

I have received lots of feedback regarding the OCS-DNS certificate calculator. Since there was some confusion, I have written this errata for clarification and also made some corrections to the calculator to make it clearer.

Please note the following:

• You can use the calculator with OCS 2007 R2 only. You cannot use it with OCS 2007 as we have not tested it against 2007. There are no plans to test it in the future, but it might be something we pursue further down the road.
• You can use the calculator for Exchange 2007 and 2010 deployments; there are no differences between both products in regards to the certificate requirements.
• For HLB (hardware load balancers) the calculator will work if you assigned the edge FQDN to the VIPs. It has been tested and will work very smoothly.
• To generate certificate request, use the OCS installer to create the certificate using the certificate wizard, then copy and paste the names generated by the certificate calculator into the certificate wizard.
• Make sure to import the certificate on the same server you generated the certificate request from and export it along with the private key. This is mandatory to be able to assign the certificate to other servers.

We have uploaded a new version of the calculator that has the following fixes:

• If you are using a certificate for Exchange and OCS, the certificate common name must be sip.domain.com or whatever the FQDN that will be assigned to the edge access and web conference. (This is a limitation that comes from the OCS that has been fixed in the current release.)
• If you cannot make the certificate common name the Edge Access FQDN, then you can use a separate certificate for the Access Edge and Web Conference Edge.
• We removed the web conference FQDN selection, since it has to match the FQDN assigned to the access FQDN.
• We added port feature, so now you can assign a port and this will help in configuring the web conference edge.

http://support.enowzone.com/Downloads/OCS-DNS-Certificate-calculator-V1.5.xlsx

Credentials

Username: enowzone\freetrial

Password: H3althCh3ck

First Consultant’s Corner post:

By: Mahmoud Magdy

Hello! My name is Mahmoud Magdy and I am honored to be hosting the first ESE Consultants’ Corner. For this edition’s post, I chose to answer several questions I recently received that will benefit our readers the most.

Q: I am sending a large amount of emails per day and I am afraid of being listed as a spammer. What are the rules regarding spam?

A: You may rest easy because you will not be listed as a spammer just because of the large amount of emails you send. In fact, you will not be listed if you send a single spam email to as many as 1,000 or more recipients. The general rule of thumb regarding spam is this: being listed as a spammer is not related to the amount of email you sent, but rather the content of the emails and to whom they are sent. If you are simply sending advertisement emails to your customers then you will not be listed, but if you send advertisements to a mailing list that you don’t own then you are busted.

However, if your email system that is sending these types of messages is not secure and properly configured, then you will be blocked. The most common errors include DNS mis-configuration, SMTP banner and FQDN, and SPF solution, among many others.

Q: We have an internal application that sends emails using our internal relay connector. Will these emails be listed as spam?

A: For the general rules, please see the answer above. In regards to your particular situation:

1. I recommend that your application uses an email address that exists inside your organization

2. Try your best to authenticate the SMTP connection using your application; this will create an authenticated SMTP connection to your relay and it will be safe.

Q: My storage guy is doing a RAID X implementation because he told me this is the best option for my storage and Exchange deployment. Do you agree with him?

A: Let me preface this by saying that storage guys usually don’t like me. They are very professional and their work is very scientific, so when an Exchange guy comes in and tells them ‘This is how we should do storage,’ it does not go over well with them!

I recommend that you design your Exchange deployment using the Exchange storage calculator or your vendor’s calculator, and ask then storage guys to give you IOPs. Don’t worry about the RAID type as long as you get the required performance. Of course your must determine if the deployment option is the most cost effective method and will provide optimum performance. Storage guys really are the best people to tell you how to design your storage, but again make sure you ask for IOPs and not RIAD.

Q: I bought a server with 24 cores, but I heard that Exchange will not benefit from it. What I shall do?

A: Multi role deployment works well with 24 cores, and can even reduce issues without using the WSRM (Windows Server Resource Manager.) The problem is more with single role deployment and cross talk, but I must warn you that there is a catch: Microsoft testing shows when environments are sized according to Microsoft current guidance, multi-role systems perform fine without WSRM. (I will put a caveat on this by saying that most of the testing was done on 8-12 core systems.)

24 core systems have been low priority, so if Microsoft does not have a linear scale then these systems may benefit from WSRM. One other thing to be aware of with 24 core Intel systems is that most of the hex core (Dunnington) processors are over 1.5 years old. Until the processor vendors release the next round of 4 socket large core processors, you may be better off running a 2 socket Nehalem quad core system over a 4 socket hex core system.

Example:

• The spec adjusted megacycles for a 24 core Intel Xeon X7450 server is 35237.
• The spec adjusted megacycles for an 8 core Intel Xeon X5570 server is 44122.

In conclusion, today you can run a higher number of mailboxes on the newer 8 core servers than older 24 core servers.

I hope our first edition of the ESE Consultant’s Corner was helpful for you. What challenges are you facing in your environment? Need an expert opinion on an upcoming project? Feel free to email us your questions at ese@enowinc.com.

I look forward to hearing from you.

Until the next post, wishing you faster processors and bigger RAMs…

Mahmoud

Labels: Exchange Support, Exchange Tips, Office Communications Server R2

posted by Enow Inc. at 8:22 AM 0 Comments

All for one and one for all: The key to a successful Office Communications Server Deployment

Please note that Those IPs will be VIPs if you use HA deployment. They will be created using HLB (hardware load balancers) since OCS doesn’t support MS WLB.

Note: You can change comp.domain.com to any name you want, just make sure to enter that name in the setup or modify it using LCSCMD command line tool.

Now let us take a look at the external DNS records used by OCS by an external User:

Keep in mind that SIP is used for Edge client access, webcon and AVconf are sample DNS entries that could be changed as they are not hard coded.

Combine it all with Certificates:

Now you have a table that lists all of the DNS names that is required, all you need to do is pull a certificate for each name (duh, that is why I am here writing this post, we want them all in one certificate). You can use single certificate, but let us see first the names that I will need to include in the certificate:

The above table list all the names required for OCS and Exchange, but there are 2 catches here:

• SAN certificates are not supported by ISA2004/2006 for SSL publishing, you will have to use ISA 2006 SP1 or TMG since this issue were fixed in both versions.
  
• If you use single certificate for Edge web conference and Edge Access, you will find that Edge server requires that names must be matched between Access/web conference IPs (you will note that in the edge server configuration wizard, you will be able to change the name, but it will not take effect), so the name must be matched, thus the same IP must be used so you will have to change the ports between access and web conference (in typical configuration Access/Web conf will use port 443, since OC clients are hard coded to try to use port 443, so you will have to change the web conf port to any other port, use 444 for simplification).

The final note has 2 catches:

• 444 is a non standard port so you might have to adjust your firewall.



• If you want to use port 443, then use a separate certificate for the Web Conference edge server IP.

You might wonder how I can change the port of the web conference without affecting the information worker, well the following diagram elaborates how web conference tokens are created:

The story begins when an external user clicks on the conference link (this external user is either domain user or anonymous user), then the following occurs:

• The users access the Access Edge server and to get authenticated (Kerberos, NTLM for domain users or digest for anonymous users).


• The front End server component contacts the web conf server component, AV component, Web component to add the user to the WEB MCU and AV MCU.


• Pay attention in this step please, the user gets back an authentication token and configuration cookies that has the web conf edge/AV conf edge configuration and this is where the client gets notified about the ports used by the edge servers.
  

So as you can see web conf and AV conf ports are not hard coded, but are passed to the user in the config tokens.

Please note the web conf, front end and AV conf servers are located in the same box, but they were separated to elaborate how they work internally.

Avoid this common mistake:

One of the most common mistakes that we encounter in OCS implementations is seeing the FQDN for the AV authentication server and the port set to 443. This is not correct and will result in calling errors on the Office Communicator client. Please make sure that the AV authentication service uses port 5062.

Now after tons of notes, let’s make our final names table:

If you follow the suggestions listed in this article you will be able to use a single certificate for Exchange and OCS. Please note that I did not cover the internal edge certificate and pool certificate names as they are fairly simple to implement.

To help you, I have created my own Exchange/OCS certificate and DNS calculator. Please note this calculator is not supported by Microsoft and you should verify your configuration with a professional OCS/Exchange consultant. The calculator is very simple to use. All you will have to do is enter the OCS sip domain, host names used by edge server, OCS server type either (standard or enterprise) and DNS names and the certificate configuration will be created for you automatically.

To download the calculator, please use the link and credentials below:

Exchange/OCS Calculator:

http://support.enowzone.com/Downloads/OCS-DNS-Certificate-calculator-V1.4.xlsx

Credentials:
Username: enowzone\ese

Password: Tool4you

I hope that in this post I was able to help you out in your deployment and eliminate the confusion caused by using a single certificate for OCS and Exchange. Have a nice deployment and see you next time . . . !

Labels: Exchange Support, Exchange Tips, Office Communications Server R2

posted by Enow Inc. at 9:31 AM 0 Comments

Understanding Exchange 2010 Storage Architecture: Part 3

Labels: Exchange 2010, Exchange Information Stores, Exchange Support, Exchange Tips

posted by Enow Inc. at 2:00 PM 0 Comments

Exchange 2003 / 2007 – IMAP Calendaring Meanderings…

Exchange is Exchange.

It’s a mail server, sends and receives mail, provides shared calendaring, you can connect it to your phone system, does a bit of task management – can be used for workflow – but other than that, and unless you integrate it with other software – that’s it.

Now some of you might be thinking – have I taken leave of my senses? – have I abandoned our favorite product? – Is that what I really think?

No – don’t panic – this was a statement that was made during a recent meeting that I had with a customer and their technical department.

Obviously I (politely) corrected this poor misinformed individual by countering “The space shuttle is a large firework, made from 2000 tons of steel, filled with 2 billion gallons of Hydrogen and Oxygen which is set on fire, and controlled by computers which until comparatively recently were still 386’s”.

The customer said to me “That’s not accurate and you are over simplifying that” – to which my point had already been made :-)

You see with Exchange many people don’t see the complexity and effort (as with the space shuttle) that goes into designing the best possible mail system for a company – and most interestingly – even after implementation, people miss the wonderful challenges that customers whom our using our Exchange systems present to us as either contractors or system administrators.

Now don’t get me wrong, customers are out life blood – and indeed the source of creativity and inspiration and one of the great things about working along side .:ENow is that it gives you real world exposure to customers requirements which to all intents and purposes demand that we think beyond the limitations of software (which can either be Exchange or a related product) or indeed at times think beyond our own personal “hang ups” that we as a system a architect as to what will be best for a customers system.

For example, I am not a fan of IMAP in regard to Exchange implementations.

Again, don’t get me wrong – IMAP is a sturdy protocol, has been used for years and indeed forms the backbone of many stable, high profile mail services on the Internet (along with the timeless POP3 protocol). However when relating it to Exchange implementations I become a bit of a “purest” and believe that when Organizations have the choices of MAPI or Outlook Anywhere or OWA I tend advise customers to not opt for IMAP (or POP3).

I (and this is a personal opinion – not reflective of the views of .:ENow) tend to look at IMAP as an additional complication, more ports to open (if you are using both secure and unsecure), an additional service running (therefore a larger attack surface) and more configuration for an admin to worry about.

Add this to the fact that IMAP is normally used with a different client such as Thunderbird (therefore an additional desktop client support) – and when sizing your Exchange databases if you have a big enough client base which requires IMAP it can represent further increase on required resources from a disk / memory perspective.

However, I cannot get away from the fact that a number of companies despite the above; need / want to use IMAP within their Exchange implementations (and in fairness there are a number of good reasons – licensing for example; you can download a decent IMAP client which will work with Exchange for free – whereas Outlook costs money) so as an Exchange Admin and indeed a service provider to customers I have a responsibility to help out where I can.

One of the most common “talked about” subjects that I (and indeed most Exchange Administrators) come across with customers whom are using IMAP and Exchange is Calendaring Access.

Most of the debate falls into the following categories:

• Cannot view other people’s calendars
• Cannot agree to, receive updates on or schedule meetings
• No Calendaring at all
• Calendaring errors with Exchange

Now, being honest with you – this article does not give you clear solutions to the above issues – as indeed some of them just don’t have a solution – they are problems which have existed for quite a long time, and indeed perhaps will continue to do so.

Microsoft nor IMAP client vendors (Mozilla being one example) do not seem to wish to divert huge amounts of development time to getting IMAP calendaring for Exchange working (perhaps it is because that Microsoft seems to include IMAP for legacy reasons but does not wish to have it as a primary connection focus for Exchange; and indeed if IMAP client vendors wrote a client to specifically work for Exchange - then IMAP and their client would cease to be an open standard) – therefore we are at the mercy of the “Add On’s” community to develop plug-ins which might help.

But what I hope to accomplish is to give you a couple of “workarounds” which can be used to make the impact of having to use IMAP clients with Exchange a little less difficult to bear.

My IMAP client of choice for this article is Mozilla Thunderbird version 2.0.0.19 using the Lightning Connector – version 0.9 many people out there will now possibly “balk” at my use of Lightning as it has been described on the web as “clunky” and indeed “under featured” – however my view is that in relation to Exchange and indeed IMAP it is perhaps the best an only solution that I have found that gives IMAP users a chance of getting near some for of calendar functionality.

We also need to understand that Lightning was developed for use as part of the Mozilla Open Source Calendaring Project as well as strong links to a dedicated Open Source IMAP server with groupware calendaring built in (a project called SOGO) therefore it was NEVER going to be all things to Exchange, but we should not over look the fact that it does provide some useful functions within Thunderbird (as Thunderbird has no inbuilt calendaring features in a default install).

Cannot View Other Peoples Calendars:

As mentioned above this article does not provide hard solutions to all the issues above – and this is one element that does not get totally solved but I can offer a work around.

The following does involve a little bit of configuration both from the client perspective and the Exchange Server – however – if you are in a position where your CEO really wants to have the ability to view the Calendars of others – and indeed will not part with Thunderbird – this might be for you.

In order for this to work you will need to ensure that you have configured the LDAP Address book correctly from within Thunderbird (this essentially connects to Active Directory and returns the GAL). For information on how you can do this please review the following link: http://joseph.randomnetworks.com/archives/2006/02/08/active-directory-as-ldap-address-book-for-thunderbird-outlook-and-mailapp/ remember that the bind DN should be your e-mail address.

One of the cool things about Thunderbird is that it is highly customisable – not only does it have a large and well supported “Plug ins” base, it also contains a feature where you can configure elements of the environment to suit your needs.

In this example I will show you how you can make use of a 3rd party plug in called “ThunderBrowse” which when combined with Active Directory script and a modification to the Thunderbird configuration enables you to open the calendars of people where the correct permissions have been granted.

Firstly you will need to download the ThunderBrowse extension from: https://addons.mozilla.org/en-US/thunderbird/addon/5373 to a suitable location on the machine where you have Thunderbird installed.

In order to install the plug in you will need to start Thunderbird then select [ TOOLS –> ADD-ONS ] you will then be presented with the following dialog box:

Click on the install button which will present you with a standard “Windows Open” dialog box – navigate to where you downloaded the “ThunderBrowse” plug-in and select it:

You will then be asked to confirm the installation – there will be a count down as this Plug-in is not signed by the publisher – when the count down is completed click on the “Install Now” button.

You will now to restart Thunderbird – when that is completed you will be taken through a very short configuration wizard – this is pretty self explanatory.

When you have completed the wizard you will be see the following change to the Thunderbird environment:

Now that you have a means of browsing via Thunderbird we now need to complete the configuration of the client before we move onto some of the server side changes that need to be made.

From the Tool menu within Thunderbird navigate to [ TOOLS –> Options ] and from the dialog box that is presented to you click on the “Config Editor” button – see below:

When you have clicked on the “Config Editor” button you will be presented with a screen which looks like the following:

You will need to locate the value <LDAP_REF>.server.default.attrmap.Custom1 (the value of <LDAP_REF> is the ID of the LDAP address book for your AD Domain – you should be able to identify this by finding the LDAP server name that you provided in the Address Book configuration (if you only have 1 LDAP address book configured there is a chance that the value will be the same as mine).

Double click on the entry and at the end add in the value (separated by a comma) “extensionAttribute1” – see below:

What we are doing here is mapping the value within AD of the Exchange Extended Attribute 1 to the Custom1 field in the Thunderbird address book – you might be thinking at the moment – why are we doing this? – well there is a purpose which I thought might be worth showing you before we continue with the configuration – the following Self Extracting Archive (in AVI format) demonstrates how, when you have finished the configuration how you can open other peoples calendars Exchange Calendars from within Thunderbird:

Exchange Calendars in Thunderbird – AVI [ 278KB (Compressed) 9 MB (Expanded) ]

This video is best viewed with VLC Media Player which can be downloaded from here: http://www.videolan.org/vlc/

Populating the Exchange Extended Attribute 1 with the OWA URL for the mailbox:

Now that we have completed the client configuration we now need to make some changes within Active Directory. Now these changes are not extravagant – essentially all we are going to do is put the URL for each user’s calendar via OWA into the Exchange Extended Attribute 1. At this stage you might be thinking “but I have hundreds of users” – so – I have provided a script (which encompasses the configuration for both Exchange 2003 and Exchange 2007).

This script will search through Active Directory finding Exchange recipients – when found each recipients extensionAttribute1 is updated to reflect the OWA URL to their calendar.

The script provided is an example only – you might want to review it and modify to suit your own needs (for example if you do not wish to update every mailbox in the directory) – however I must stress that it is provided “as is” – I have used it within my own LAB environment where it worked fine, however, I recommend that you test them yourself before using them in a production environment.

Neither I nor .:ENow can be held responsible for any undesirable effects that co-incidentally arise as a result of using the following script.

Custom Attribute Modification Script [ 2KB ]

In order to use the script – download it to either a domain controller or Exchange server within your organization, double click on it – where you will be prompted for three items of Information:

1. The name (this can be DNS name) of your OWA Front End or Client Access Server

2. If you are using SSL

3. If you are using Exchange 2003 or 2007

When you have provided the above the script will execute and update extension Attribute 1 of each recipient in Active Directory with the OWA URL to their calendar – see below:

You will now need to ensure that the /Exchange can support anonymous connections – this can be achieved via the Exchange System Manager (within Exchange 2003) by going to [ Administrative Groups –> Servers –> <Server Name> –> Protocols –> HTTP –> Exchange Virtual Server –> /Exchange ].

In Exchange 2007 you will need to ensure that you are logged onto the machine with an account which has permissions on the person’s calendar as Anonymous access is not supported.

Now that we have both the client and the server end configured, the remaining configuration is taken care of by configuring permissions within the mailboxes of people whom you want to grant access to – for example – within my Lab – I want my account (which is configured as the IMAP user and called Andy) to have access to the calendar of the administrator.

What I would need to do is logon as the administrator and assign the correct permissions to the calendar (as you would normally do) – typically I would grant “reviewer” access as the default permission (this will depend on your organisation).

Putting it all together:

Now that you have configured the client (by adding in the LDAP address book, configuring the LDAP mappings, and installing ThunderBrowse) and also configuring the back end – you are now in a position to use Thunderbird to access Exchange calendars as per video example above.

An example of what a populated calendar would look like is below:

Cannot agree to, receive updates on or schedule meetings:

One of the first things that you will notice about Thunderbird is that it does not (in a default install) contain any form of calendaring (not even a personal calendar). This however can be mitigated by downloading another Plug In called “Lightning” https://addons.mozilla.org/en-US/thunderbird/addon/2313.

The Lighting Plug-in is installed in the same way as ThunderBrowse - which I went through above. When installed you will see within the Thunderbird client that you now have access to a calendar – more to the point, when you are sent meeting requests, rather than appearing as plain text e-mails, they will now show up like the following:

As you can see you have the ability to Accept, Decline or Tentatively accept meetings or appointments – which are then added into the calendar. You can also create and send meeting invites – which when combined with the workaround above (for viewing others calendars) give you the chance to see if people are available.

IMAP Meeting errors with Exchange:

I have heard and read about some people experiencing errors within their IMAP clients when trying to open or read calendaring invitations sent from native MAPI Exchange clients.

Typically (although not exclusively) errors manifest themselves in the Exchange event log as (for example):

Event Type: Error
Event Source: IMAP4SVC
Event Category: Content Engine
Event ID: 1023
Date:  8/13/2008
Time:  7:56:47 AM
User:  N/A
Computer: <Computer>
Description:
Error 0x7da occurred while rendering message 0001-0000001cded6 for download for user <User>.

For more information, click http://www.microsoft.com/contentredirect.asp.
Data:
0000: 07 0c 0d 00               ....   

It is possible that the client will also throw an error when trying to open the offending invite.

Personally I have found that if you use the latest version of Thunderbird and ensure that your Exchange servers is up to date with the latest patches errors such as the above do not happen, however if you encounter such and issue it might be worth following the advice above – and following the processes which are given in the following articles:

http://support.microsoft.com/kb/329168

http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/c63b8713-9ef9-4076-a11b-5db08255689b/

Summary:

Well that is it for another month – I hope that you have enjoyed this little ramble through the world of Exchange and IMAP – if you should have any questions, please feel free to comment!

Labels: Exchange 2003, Exchange 2007, Exchange Support, Exchange Tips, IMAP

posted by Andy Grogan at 10:44 AM 1 Comments

Things that can be missed in Exchange 2007 migration planning...

Let's be honest - Exchange 2007 is a beast of a product, and indeed potentially a bigger leap in redesign than the jump from Exchange 5.5 to 2000. From a management perspective it has forced many Exchange Administrators to rethink their administration policies and learn new technologies which prior to Exchange 2007 they would perhaps not considered being part of their skills arsenal.

For example; In Exchange versions 2000 to 2003 - Exchange admins did not necessarily need to be a scripting guru in order to do his/her job. However in Exchange 2007 the integration of the Exchange Management Shell (based upon Powershell) and the amount of configuration options that the Management Shell controls which are not in the Exchange Management Console an Exchange administrator needs to develop at the very least, an understanding of basic scripting techniques - even if this is at the single command level.

In the case of Exchange admins whom run larger Exchange 2007 installations (or indeed consultants and architects) the skill with the Management Shell need to be "ramped up" in order for them to achieve their deployment goals - and indeed get the very best out of the product - this can (in some cases not all) move Exchange Admins out of a "comfort zone" and into a world where they are almost part Exchange Systems Admin and part developer (a hybrid).

Of course the changes are not just limited to mere scripting - the major Architectural changes that Exchange 2007 has brought with in - for example the move to x64 Hardware being the only supported production platform.

In previous migrations between Exchange versions we were all safe in the knowledge that we had the option of "in place" upgrades on the same hardware (if it was up to the job) - in many cases now companies are in the position of having to purchase new hardware to meet or indeed supplement the the demands of Exchange 2007.

Closely linked with the above is the inception of "Exchange Server Roles".

Roles are not only just a big conceptual change, but have a significant impact on the specification of your Hardware and topological layout. People whom are embarking upon a migration path to Exchange 2007 need to work through the processes of sizing (specifying their hardware according to the role that it will be performing - examples of good sizing articles on the Web are:

• General all in one
  
  Exchange 2007 sizing cheat sheet
  
• Hub Transport / Edge Transport Server
  
  Suggested Hub Transport Hardware Config for Exchange 2007 Installations of 5000 users
  
  Capacity and Transactional IO requirements for Exchange 2007 and Edge Transport and Hub Transport Servers
  
• Mailbox Server
  
  Exchange 2007 Mailbox Server Role Storage Requirements Calculator
  Mailbox Server Storage Design
  
• Client Access Server
  
  Planning for the Exchange 2007 Client Access Servers
  
• Unified Messaging
  
  Using Exchange Server 2007 for Unified Messaging and FAX

If you spend time looking through the above you will see that there is a significant increase in the amount of work that is required to correctly size your Exchange installation - there are of course other choices that need to be made - for example:

• Do you cluster?
• If you cluster - which clustering technology do you use (CCR, SCC?)
• If you are not using clustering do you place all the compatible roles on a single server?
• If you wish to split the roles out do you choose to have dedicated mailbox servers with HT and CAS running on another server?
• Do you use the Edge Transport Role?

All of the above can (and should) take weeks - perhaps months to correctly ascertain - and remember all of this is before you even place the DVD in the drive.

At this stage you might be tempted to overlook the sizing requirements of Exchange 2007 in favour of taking a "Best Guess" - however I urge you not to, Although the sizing calculators and advice look intimidating your should not underestimate the revised Disk I/O and Memory requirements for Exchange - these tools and articles are there to ensure that you do not run into issue later on down the line with the specifications that you have determined.

To add to the complexity of migrating to Exchange 2007 you also need to ensure that your existing Exchange and Active Directory environment  meets the recommended specifications and that you are ready for the added administrative overhead that occurs during the co-existence phase of your migration - it is worth reviewing the following articles before you install Exchange 2007 into your environment:

Exchange 2007 System Requirements

Planning for Co-Existence

Managing Exchange 2003 Settings in a Co-Existence Environment

By reviewing the above articles you will reduce the risk of problems during the Schema, Domain and Exchange setup processes however there are some other things that you should take into consideration before you begin:

• If possible in your Organisation institute a "Lock Down" policy on Active Directory for the period of the Exchange installations - essentially ban any account modifications and directory structure modifications - this will make the process of a restore much simpler should you need to.
• Take backups of ALL FSMO role holders BEFORE you begin the Schema / Domain preparation processes
• If you are extra cautious and your schema master is a separate role holder from all the other domain controllers you can perform the Schema updates "offline" so to speak by either disabling replication via RepAdmin tool. This will prevent the changes from being sent to the other directory databases until you have verified that the Schema has been updated properly
• You should disable local Anti Virus during any Exchange installation process
• When installing the first Hub Transport into your environment it will create a routing group which ensures mail flow between Exchange 2003(2) and Exchange 2007 - you should take an Active Directory backup prior to the installation of the HT role - this will help you roll back should anything go wrong during the process (for example I had a support call where a person had not opted to create the Routing Group and then tried to manually create it - potentially it would have been quicker to restore from backup considering the amount of time that we spent troubleshooting it)

The above are just some of the many things that need to be considered on the road of the upgrading to Exchange 2007 - however to conclude this article the following are a number of other commonly overlooked or indeed misunderstood concepts when migrating:

• Store Based Anti Virus Programs are not updated
  
  If your existing Exchange 2003 servers make use of VSAPI based checkers (for example McAfee Group Shield, GFI or Norton) you will almost certainly need to upgrade them for Exchange 2007 - this might represent additional costs for your migration if you do not have Framework licensing for your products.
  
• Backup Tools and Agents
  
  Significant changes have been made to Exchange 2007 at the store level to allow for both streaming (being depreciated and not in Windows 2008) and VSS based backups. You should check that your existing backup product supports Exchange 2007 - and if you have installed Exchange on Windows 2008 you will need to upgrade your backup so that is knows that Streaming has been removed and VSS is the primary backup system.
  
• Archival Products
  
  If you make use of a commercial Compliance product such as Enterprise Vault you will need to ensure that it supports Exchange 2007 - and also that any integration features (for example with OWA) are also fully supported.
  
• Windows 2008
  
  Many people whom are embarking on Exchange 2007 SP 1 migrations will almost certainly be tempted to use Windows 2008 as their Operating System platform (and so they should) - however remember that Windows 2008 is a pretty large departure from Windows 2003 (certainly in terms of IIS and clustering). You should also consider any product that uses an Agent to communicate with Exchange (for example Enterprise Vault) is supported on the Operating System.
  
• Depreciated Support for MAPI and CDO 1.2.1 and ASP Database based applications
  
  MAPI / CDO is no longer supplied as part of the default Exchange 2007 install - therefore you should note that if you have an application which resides on your Exchange servers which makes use of CDO it may cease to function - you can download the components from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=E17E7F31-079A-43A9-BFF2-0A110307611E&displaylang=en.
  
  Additionally if you make use of a ASP based solution which communicates with a Database you need to know that it could experience issues on a x64 platform (you will need to check that there is x64 ODBC driver support).
  
• Remember your Accounts Team
  
  For larger organisations it is possible that you have a dedicated accounts management team. Exchange 2007 re-adopted the Exchange 5.5 administrator model whereby accounts can be created in Active Directory Users and Computers - however the mailboxes need to be created via the Exchange Management Console or Indeed the Exchange management shell.
  
  Again like Exchange 5.5 from the Exchange 2007 Management tools you CAN create both the Active Directory account and the Mailbox - however if you need to add the user to groups and configure Terminal Services profile settings for example you will need to go back to ADUC to finish the job.
  
  What I recommend is that you get your Accounts People to work with the account in ADUC and then supply them with a Powershell script which will configure the mailbox settings as required - all they will then need is a copy of the Exchange Management Tools and Powershell on the machine with the required permissions.
  
• Consider your permissions model
  
  Linked to the above you should give careful thought to the permissions and roles that you assign to people - there is a good article here which will provide you with help in making these choices: http://technet.microsoft.com/en-us/library/aa996881(EXCHG.80).aspx
  
• SSL, the Client Access Server and the Auto Discover Service
  
  If you look at the Exchange server forums which litter the Internet you will find hundreds of posts which deal with the above. The AutoDiscover service is perhaps one of the most complex things to get to the bottom of (as it is linked very closely with correctly configuring SSL, the configuration of Outlook 2007 clients).
  
  Before you deploy users to your 2007 organisation ensure that you FULLY understand Auto Discover and SSL on CAS servers - the following are some very good links which will help:
  
  Whitepaper - Exchange 2007 Autodiscover Service
  Exchange Genie - Exchange 2007 Autodiscover Service Part 1
  
• Exchange Analysis Tools
  
  If you make use of any Exchange Analysis or Monitoring tools (for example Mailscape, OmniAnalyser, MOM 2005) ensure that they are compatible with Exchange 2007 - and upgrade them if they are not.

Well I think that I have rambled enough for this particular article - and I hope that it has given you some good pointers and food for thought before you embark upon your own personal migrations.

Labels: Exchange 2007, Exchange Migration, Exchange Support, Exchange Tips

posted by Andy Grogan at 11:28 AM 0 Comments

To Offline Defrag or not to Offline Defrag that is the question...

Reproduced with permission from TelnetPort25.

Many Exchange Admins will come across this conundrum at some point during their careers - essentially when is it good to defrag your Exchange databases. There are of course many different views expressed by many different Exchange administrators on this particular subject - therefore in this article I would like to share some of my own personal thoughts on the subject.

As many of you know ESEUTIL is the tool supplied with Exchange that allows for an Offline Defrag to happen before I begin I would like to do a brief overview of ESEUTIL.

What is ESEUTIL?

ESEUTIL (located in the <Exchange Installation\Bin Folder> – might be considered by many to be the dark over-lord of database utilities which, in the blink of an eye can reduce your information store to a quivering mass of non-functional dog do-do, and accelerate the demise of your career as an Exchange Admin.

However, is ESEUTIL really that bad? – I suppose that the answer to this is yes and no as using the tool incorrectly – or – when it is not need can produce undesirable situations – the following are some quick bullet points about the Pro’s and the Con’s of using the ESEUTILS:

Pros:

• Using ESEUTIL correctly and when required (more on this later) can physically reduce the size of your information store databases
• When you have no other options left and you have a dead database ESEUTIL can get you some data back (by using the dreaded /P switch)
• ESEUTIL can be used in a recovery scenario to roll forward to a specific point post a disaster as long as you have the Transaction Logs (but then again so can most decent backup products for Exchange)
• ESEUTIL can be used to check the structural health of your database
• ESEUTIL can be used to clone your database

Cons:

• Its command line based, messing up a command could leave you with a dead database
• Any Database that you intend to run ESEUTIL against must be off-line – therefore users cannot access the system resulting in lengthy down-time
• Its slow – Depending on your hardware ESEUTIL will run at around 3 – 6 GB per hour (under a repair) and can be in-determinant during defrags
• Its not intelligent – this is dangerous, for example – a Defrag process creates a new database, copies useful data from the old database to the new and then deletes the old PRODUCTION database and renames the TEMP database to the same name as the old – what if power is cut to the server during the Production Delete? and the rest of the process does not finish – ouch!

Generally speaking you should only use ESEUTIL under the following Circumstances (there are generally no exceptions):

• When you have no usable backup of your Exchange Databases – Repair Scenarios
• When you have had a lot of transient behaviour in the database – Defrag Scenarios – for example;
  • A large number of users have either left the company, or moved to another store within the environment
  • You have installed a archiving solution into your environment and it has been running for at least 5 months
  • You have hit a limit on the Database (in the standard Edition of Exchange only) – this scenario should not happen when using SP2 of Exchange 2003 or Exchange 2007
• When you have good reason (good means Application Event Log errors) that suggest a corruption in the Database – Integrity Scenarios
• When you wish to replay log files into the Database
• When it is recommended by Microsoft Product Support Services, or when you are confident about using the command syntax and you are sure that it is going to be of benefit to you

OK, But I am still interested in ESEUTIL – can you give us some further information?

ESEUtil is designed to check and fix individual database tables based around the JET BLUE engine, however products like Exchange are comprised of many structured and complex pages (which can be either 4 or 8 kilobytes in size) which in turn are linked via indices which are accessed sequentially (this is called ISAM).

As a result ESEUTIL is not Necessarily aware of the data contained within the database pages – nor the relationships between database pages. The results of which when ESEUTIL is used for example using its “Hard Repair” (/P) mode, when it finds a damaged page or index it deletes it, nothing else, just deletes. Given the previous scenario you may of had a database that will not Mount – however /P will potentially get you into the position where it will Mount – but you will normally find missing data within Exchange.

An example of which is many years ago when consulting I encountered an Exchange 5.5 system where the Information Store would not start. There was no backup therefore I had to use ESEUTIL /P in order to get the store to start – ESEUTIL fixed the database and the store service then started, however, every user in the database lost access to all their attachments (the icon would show in Outlook indicating that the message had an attachment, but attachments could be accessed).

Additionally ESEUTIL can be used to de-fragment, check the Integrity of, recover (Hard and Soft), copy, checksum, and dump various informational aspects of your databases.

ESEUTIL – De-fragmentation Mode [/D];

OK, now that we have had a brief look at ESEUTIL and indeed established that it is indeed a tool that needs to be respected - I would like to go over the command switch of ESEUTIL which most people to ask Questions about the DEFRAG – or – the /D Switch.

The de fragmentation Mode of ESEUTIL is designed to reduce the physical size of your Exchange Databases – as online de-fragmentation does not physically reduce the size of the DB – is essentially performs internal maintenance within the Exchange Database.

It does this by creating a temporary Database file, reading through the live database page by page and copying all relevant data into the Temp database (note it skips over white space identified by the online maintenance (event ID 1221) in the Live Database) this process is generally known as re-organisation.

When all of the data from the live database is copied over into the temp database, the live instance is deleted and the temp database is renamed to that of the previous live instances (although this is a very simplified overview of the command).

All indexes in the database are also recreated as part of this process.

You should be aware that you will at least 110% of the size of your production database free on the drive in order to have a successful de fragmentation, although should this not be possible you have the option of either redirecting the Temp file to another disk on the server – or – by following the steps in this article http://articles.techrepublic.com.com/5100-22_11-5285289.html you can copy all of the required files to another server with enough space to handle the defrag, but bear in mind that you will have to copy the database back from the additional server which adds to the overall down-time of your mail system – and also introduces the (small) chance of corruption during the copy back from the source server over the network.

The basic command syntax for the De-fragmentation command is as follows:

ESEUTIL /D <path to database file> – for example ESEUTIL /D x:\EXCHSRVR\SG1\DB\Priv1.edb

There are a number of partner command line switches which accompany the de-fragmentation mode which are as follows:

/S – Specify the location of the Streaming File (this option is not implemented in 5.5 or 2007)

/T – Specify the location where the Temp Database file is to be created (useful if the disk that the database is on does not have enough free space to complete the De-fragmentation)

/F – Specify the location and the name of the temp streaming file (this option is not implemented in 5.5 or 2007)

/I – Do not de-fragment the streaming file

/P – Do not delete the temporary database files at the end of the process

/B – Make a backup copy of the database

Given the above commands and options – if I wished to defrag my Priv1.edb which is located on Drive X:, but place the temp file on L: I would use the following command:

ESEUTIL /D x:\EXCHSRVR\SG1\DB\Priv1.edb /T L:\<tempFile.tmp>

From the above you can derive that the syntax for a successful command is: ESEUTIL /D <Path to DB> <Options – e.g. /T>

One of the questions that many people ask how much space can they generally expect to claim back by performing an off-line defrag on their information store – the answer to which is pretty difficult to give, and should be mainly based around minimum expectation.

For example: the normal and widely accepted way to gain an idea is to check the Event Log for Event ID 1221 – see below:

Essentially the part of the Event Description which states “has ‘n’ megabytes if free space” is the bit that you are interested in.

This the value of ‘n’ in the Event is generally described as the least amount of space that you can claim back (to within one megabyte).

There is another way in which you can calculate the amount of space that you might gain back – however it does require you to take the database off-line to perform the process.

Although this is a pain – I have found this method to be pretty accurate when determining space reclamation metrics:

• In the Exchange System Manager Dismount the Database that you wish to process
• Open a Windows Command Prompt ([ Start -> Run -> Type CMD the press <Enter> ]) and type in the following command:

ESEUTIL /MS <path to edb file> >c:\Analysis.txt then press enter – see below

This will produce a text file (located in C:\) called Analysis.txt – when you open this file you will see that it is split up into two sections:

SLV Space Dump – this relates to the STM File (not in Exchange 2007) – see below:

At the bottom of the SLV dump (you will find a section entitled “TOTALS”) here there is an entry called “FREE” – the value of this when multiplied by 4096 (this length of a database page in Exchange 2003) will give you the free space in the STM file in bytes – so from my results above:

78 * 4096 = 319488 bytes

319488 bytes = 312KB – space that could be reclaimed

The other section of the report which is called the SPACE DUMP (which is much longer than the SLV dump as it relates to the EDB file) – looks like the following (please note that the following example has been cropped):

At the bottom of the SPACE DUMP on the far right hand side (under the “AVAILABLE” column) you will have a value.

In my case this value is 524, again this is the free space in bytes – therefore in order to determine how much space that I would get back I would use the following calculation:

524 * 4096 = 2096 KB – space that could be reclaimed

Checking the Event 1221 events is easy and does not cause any disruption to normal operations, however using the ESEUTIL /MS does require the store to be off-line – personally I feel that using the ESEUTIL /MS command gives you a more accurate representation of the space that could be recovered, but you need to be aware that it does cause disruption – however if you are considering defragging your Exchange Databases you could build the space analysis in the down-time required.

I would personally only use the ESEUTIL /MS method to check for potential space under the following circumstances:

• When a large number of people (much greater than 500 users whom were heavy users) have left the organisation and their mailboxes have been deleted from the store (Purged)
• When a company instigates a program such as Mailbox Archiving where mail items going back many years are removed from the store
• You know for a fact that there are been no defrag performed on the store for a number of years (at least 3 years).

Now that we have an idea about how much space MIGHT be reclaimed, the question that needs to be answered is – “Do I actually need to defrag the database?”

Do you Need to Defrag Your Database?

OK lets consider the basic reasons why an Exchange Admin would consider De-fragmentation of one of their databases and then go over some explanation of as to why a DEFRAG might not be your first option even though it might seem so:

• Performance issues
• Running out of space on the Database Disk
• General Space reclamation
• When asked to by Microsoft PSS

Performance Issues:

One of the first things that I would like to address is that having a large database does not always mean that you will have poor performance.

In Exchange 2003 Enterprise Edition the theoretical maximum size of a single Database can be 16TB (or as often described “unlimited”) whereas in Exchange 2003 SP2 STANDARD Edition the maximum size of the Database is 75GB – however in practicality one would assume that there must be a point where Size = Performance.

I have seen Exchange Database instances which have reached sizes between 190 and 220 GB (and I also know of larger sizes) which perform very well, however the underlying hardware has been specified to cope with the IO and Operation Per Second (IO/OPS) demands that such a size would require. It should also be noted that an Exchange Database should be cared for – they should be monitored, have sensible online maintenance windows which complete and backup regimes that are successful and serviced sensibly.

Diametrically – I have also seen Database sizes of 56 GB which perform very badly, this can be linked to the hardware, online maintenance does not run correctly and no form of checks are made upon them.

So in terms of the [ Size = Performance ] theory (considering the statements above), the outcome means that the formula (as stated) might change to:

Size (of DB) + Administrative Specification + Administrative Habits / User Habits = Desired Deserved Performance

Essentially if you specify your hardware according to accurate load, ensure that required routines run against the databases (and do not overlap with backup schedules) then you can expect the overall physical file sizes to reach significant proportions without manual intervention, however if you do not follow initial sizing guidelines and allow for your Exchange server to proceed un-monitored and do not regulate the actions of your user population then your are asking for trouble.

In terms of my statement “regulating the actions of your user population” – There is another school of thought (on overall performance) right from the development team of Exchange) where it is stated that the amount of items in “Critical Path Folders” – e.g. Inbox, Calendar, and Sent Items can also have an effect on the performance of a user / database – have a look at the following article here: http://msexchangeteam.com/archive/2005/03/14/395229.aspx (and read the comments) – essentially if you allow for your users to use Exchange as a “Filing System” you might (or perhaps will) experience performance issues.

So in summary if you are experiencing performance issues with your Exchange Databases, before you consider using ESEUTIL to defrag, have a look at other root causes. As mentioned above it is possible to have really large EDB files and acceptable performance, so in the first instance use tools such as PERFMON which will give you useful information about what your Exchange Server is doing.

The following is a link to the Microsoft’s Exchange Performance and Scalability Guide here you will find an overview of which counters within PERFMON are relevant to Exchange (http://technet.microsoft.com/en-us/library/aa996078.aspx) I also recommend that you down-load the PerfMON Wizard which automates the configuration of a number of counters that can provide data regarding the performance of your Information Store.

Also if you experiencing performance problems it is an idea to have a check what is going on inside your Exchange databases – this can be accomplished by opening up the Exchange System Manager then navigating to the following: [ Administrative Groups -> Servers -> Your Server -> Storage Group -> Database Name -> Mailboxes ] and have a look under the “Total Items” column readings here will give you an idea if any (or many) of your users are falling into the criteria which the article on the Ms Exchange Team blog describes.

My final comments on performance are that you should ensure that the setup and configuration of you Exchange Disk subsystem is configured and specified to the load and size of the database – if you are experiencing performance problems – before even considering a Defrag have a look at the following:

• Are you using the correct RAID levels for your Databases and Transaction Logs (RAID 5 (or 10) for Databases RAID 1 for Transaction Logs)
• Have you separated out your Transaction Logs from your Databases
• Does each database exist on its own LUN
• Move the TEMP/TMP to a high performance drive
• Are you using 10K or 15K drives?

If you have gone through all of the above and feel that everything is is, then it might be worth considering Defragging the Database.

Running out of space on the Database Disk:

From what I have seen in the Forums this is one of the most common reasons for administrators wishing to run ESEUTIL /D.

Wherever you can the best option is to add further disk and the move you databases over to the new storage rather than Defrag; I say this as generally you are never looking at huge amounts of space being reclaimed from your Databases when you use ESEUTIL in defrag mode – so in the end you are putting off the inevitable (running out of space) so the best option is to bite the bullet so to speak and add further storage.

To give you an idea of storage reclamation I recently ran a Defrag against my corporate databases and the following are the space saving results (bear in mind that it has been 3 years since I last defragged the stores, and for two of the 3 years we have been using Enterprise Vault:

As you can see for the time periods involved, the amount of users and the presence of an Archiving solution the space savings are not huge.

However if you are not in a position to increase the storage within your server then you would have little choice but to use ESEUTIL /D however I would recommend the following prior to running the defrag:

• Examine the Application Event Log for ID 1221 – or perform a ESEUTIL /MS against the databases (then use the method of working out the potential space reclamation from above) - this will help you work out how much space you will get back – you might be faced with a situation where the amount of space that you reclaim is only enough for another month – therefore you will need to present a business case for upgrading the server.
• Ensure that you backup your Databases prior to running the Defrag
• Prepare your business for down time – depending on the hardware that you have and the size of your Databases ESEUTIL /D can take quite a while to run (for example if you look at my table above SRV2–GeneralStorageDB.edb took 17 hours to complete – and that was without any other databases mounted or being defragged on the same server).

General Space reclamation:

General space reclamation suggests that an administrator is using ESEUTIL /D as part of a scheduled and regular maintenance task. Please do not do this – from the examples that I have given above even with high user turn over, an archiving solution and several years between defrags I only claimed back slightly over 21 GB from 12 Databases if you examine the tables from a per database perspective the actual space reclaimed represents a very small percentage of the overall size of the DB.

Scheduling regular Defrags (for example every 6 months) only guarantees that your database will be off-line for several hours every 6 months.

If you have the inclination to reclaim space periodically and you are Using the Enterprise Edition of Exchange server – then perhaps a better way of doing this is to create a new database and then move your users over to the new database. This eliminates down-time and also serves the same purpose as defragging.

When asked to by Microsoft PSS:

Those of you whom have support agreements with Microsoft may be asked to defrag a database as part of a support call.

Normally PSS will be trying to get an index rebuild rather than being interested in shrinking the size of the database – however, they know what they are doing – but ensure that you follow their instructions to the letter.

Summary:

Ultimately your Exchange database belongs to you, therefore as an Admin you are best placed to make a choice on the course of action that you wish to take. The above is general advice from experience – however it may not fit all scenarios, so just to finish if you are going to perform this task please consider the following pointers:

• Always ensure that you have a backup of ANY Exchange Database that you are going to Defrag – ensure that you have tried to restore it prior to starting.
• Understand that Defragging is a lengthly process – your database will be out of action for a significant period of time.
• Ensure that your server has a working UPS – nothing worse than a power outage right in the middle of using this tool.
• If you have the Enterprise Edition of Exchange – consider creating a new store and moving the users over rather than a off-line defrag.
• If you have performance issues consider the performance area and the options given there before Defragging – there is nothing worse than taking your database down for 10 hours and then getting no perceivable benefit.
• Do your homework on the amount of space you might get back – similar to above, nothing worse than 10 hours down-time and only getting back 1 GB
• Don’t use ESEUTIL /D as part of a regular schedule – its not worth it.

This article was provided by: Andy Grogan

Labels: Exchange 2003, Exchange 2007, Exchange Information Stores, Exchange Support, Exchange Tips

posted by Enow Inc. at 10:15 AM 3 Comments