Exchange Server 2007 introduces many new and really well defined recipient types. One of them is the one my customer asked me about. The process to create a Shared Mailbox will create a disable Active Directory user as there is no point to have it - that is not the purpose of this recipient. On the old and still actual days of Exchange Server 2003 or older, when we created a Shared Mailbox  we basically created an Active Directory account with an associated mailbox and those credentials would be shared within who needed to use it. What is the issue here? Security! Was never a good idea to more than one individual login with same credentials. Control on it would be inexistent.

So in Exchange Server 2007 what we have is a mailbox with a disabled user and in a way we can give access to users or distributions lists we just add the proper permissions to the mailbox and it is done.

First of all we need to create our Shared Mailbox and to do that we need to use the Exchange Management Shell!

[PS] C:\>New-Mailbox -Name "mailbox" -Database "database" -UserPrincipalName mailbox@domain.com -Shared

At this stage we have our mailbox created and our active directory user disabled...

However now we need to give the right permissions...

Let's start by giving instructions to the shared mailbox that a few users should have Full Access on it, otherwise won't work. Advice here is do this to a Security Group more than to individual users by the same reasons referred above. Let's do it then to the users on the Sales Team!

[PS] C:\>Add-MailboxPermission "mailbox" -User "user" -Access Rights FullAccess

Almost done but a couple more things to do. At this stage the users on the Sales Team can access totally the mailbox however they still can't send e-mails from the shared mailbox. To do that we need to give them some permissions in Active Directory side...

[PS] C:\>Add-ADPermission "mailbox" -User "user" -ExtendedRights Send-As

At this stage the Sales Users are GOD within the Sales Team Shared Mailbox.

With Exchange Server 2007 Service Pack 1 we can actually setup the Full Access and Send As permissions. Basically we just right click on the Shared Mailbox and add the recipients to the desired permission or just select the account, and on the right hand side of the console you will see the same options.

And that's it!

Hello there,

Recently I had been helping a customer in a migration from Exchange Server 2010 to Exchange Server 2013. All went pretty normal, actually some of the steps were easier than I thought they would be, but there was a tiny little (and very annoying) surprise – the DAG creation kept failing…

Basically I just assumed that all would be good and would be pretty much next, next, finish… And that I’d not need to do nothing manually.

CNO Pre Staging is something that I assumed that would not need to do, however that was the only way to make it work…

Basically I run New-DatabaseAvailabilityGroup and all went well… After that was the time to do start adding members, and when doing it was getting the bellow failure:

A server-side database availability group administrative operation failed. Error The operation failed. CreateCluster errors may result from incorrectly configured static addresses. Error: An error occurred while attempting a cluster operation. Error: Cluster API ‘”CreateCluster() failed with 0×5. Error: Access is denied”‘ failed.. [Server: MBX1.fabrikam.int]

Only way to fix it was either:

• Disable CNO, assign “Full Control” to ETS on the DAG object and remove mailbox server from permissions list on CNO. Add mailbox server to DAG.
• Delete CNO from AD and pre-stage CNO using process described in http://technet.microsoft.com/en-us/library/ff367878(v=exchg.150).aspx. Add mailbox server to DAG.

After that all was good…

Bottom line here is, and after some good email threads with some colleagues, the CNO for a DAG should always be pre staged regardless of Exchange version, Windows version, or AD version.  It greatly reduces the failures due to access denied for the many other reasons that can cause access denied.

After running into this, I’ll pre stage regardless of version used from now on, save a lot of headache.

Thanks a million,

Microsoft Information Technology (Microsoft IT) maintains a complex Microsoft® Exchange Server environment that consists of several geographic locations and multiple Active Directory® forests. There are 16 data centers, four of which host Exchange servers, to support more than 515 office locations in 102 countries with more than 180,000 users. These users include managers, employees, contractors, business partners, and vendors. Microsoft IT transitioned this environment to Exchange Server 2010 in less than seven months by taking advantage of its growing automation infrastructure and the enhanced deployment features available in Microsoft Exchange Server 2010, in combination with proven planning, design, and deployment methodologies.

Before an Exchange Server release can ship, it has to be thoroughly tested in the production environment. The deployment of Exchange Server into the corporate environment is quicker with each release. For Exchange Server 2010, production testing began in February 2009, one year before Exchange 2010 was available. The entire company migrated to a release candidate (RC)—several months before release to manufacturing (RTM) occurred in September 2009. Microsoft IT accomplished this despite the challenge of testing the Windows® 7 operating system and Microsoft Office 2010 at the same time.

At Microsoft, Microsoft IT and the Exchange Server product group work together closely. Microsoft IT must sign off on a release before the product group can ship it to customers. This relationship is critical to identifying show-stopping factors during the release process.

This technical white paper discusses the Exchange Server 2010 architecture, design, and technologies that Microsoft IT chose for the corporate environment. This paper also discusses the strategies, procedures, successes, and practical experiences that Microsoft IT gained during the planning and design phase. Common planning and design tasks for many Exchange Server deployment projects include server design, high-availability implementation, and capacity planning. In addition to these tasks, transitioning a complex messaging environment to run on Exchange Server 2010 entails specific planning considerations regarding directory integration, routing topology, Internet connectivity, client access technologies, and unified messaging (UM).

The most important benefits that Microsoft IT achieved with the production rollout of Exchange Server 2010 included:

• A reduction in input/output per second (IOPS) of 70 percent since Microsoft Exchange Server 2007. The database optimizations of Exchange 2010 provide better performance and reduced storage costs. This results in a savings of more than 50 percent in the total cost of ownership (TCO) of storage.

• An increased Mailbox size of 5 GB for all mailboxes in the organization.

• Increased mailbox migration velocity over Exchange Server 2007, which enabled Microsoft IT to migrate the entire company much more quickly.

• Elimination of backups, which saves millions of dollars per year.

This paper contains information for business and technical decision makers who are planning to deploy Exchange Server 2010. This paper assumes that the audience is already familiar with the concepts of the Windows Server® 2008 operating system, Active Directory Domain Services (AD DS), and previous versions of Exchange Server. A high-level understanding of the new features and technologies included in Exchange Server 2010 is also helpful. Detailed product information is available in the Exchange Server 2010 Technical Library at http://technet.microsoft.com/en-us/library/bb124558.aspx.

For security reasons, the sample names of forests, domains, internal resources, organizations, and internally developed security file names used in this paper do not represent real resource names used within Microsoft and are for illustration purposes only.

In order to obtain the full technical white paper visit http://technet.microsoft.com/en-us/library/ff829232.aspx.

I think everyone understands that it’s not possible to select a specified disk from the DPM storage pool as a target disk for a specific protection group, however we can always move data between disks as far as the same DPM server has access to both disks.

Lets suppose we have ten protection groups and ten disks, and we moved data of a particular protection group (let’s say that data was written in disk one and disk two) to a particular disk (let’s say disk three).

Does that mean that DPM will never ever use disk one and disk two for this particular protection group and will always use disk three or can it use disk three along with any other disks, except for disk one or disk two?

To try to contextualize this a bit better, let’s imagine that we’ve attached a new disk to the storage pool of DPM and we want the data of a particular protection group to end up there.

Maybe an odd request however some customer ask for it…

The trick here will be to use custom volumes instead of the DPM storage pool. So basically after we add the new disk we can just create a custom volume on it – we just need to make sure we convert it to dynamic before anything else just in case we need to stretch it or shrink it…

DPM cannot allocate space on any disks not in the DPM storage pool, so using custom volume on disks outside the storage pool will ensure that the disk is only used for the data sources you configured (or migrated) to use that disk.

After this we need to migrate the data sources to this recently created custom volume. Just a quick note which may be handy – we will need two custom volumes per data source, one for replica and the other for recovery point.

If you check this other post you can see an example of migrating a data source from DPM storage pool to custom volumes…

http://blogs.technet.com/b/sjimmie/archive/2012/05/07/data-source-migration-to-custom-volumes.aspx

Have Fun!!!

There are brilliant news for RCA users, owner team has made an awesome effort in listening to customers feedback and change quite a few issues or let’s just say a bit more annoying than what it should be operations!

Check it out below…

For more info check Release Notes!!!

I was trying to pull some stuff together for a customer who’s contemplating going from Exchange 2003 to Exchange 2010 and looking for slides/charts comparing the two. This may be useful to some of you, as so here it is.

In conversation with a good friend, David Rankin, also known as The Highlander, and because I was in the middle of a Data Protection Manager 2007 Health Check and needed to check builds, versions, patches applied etc. he kindly help providing me his wonderful list which I am publishing here now! It is not rocket science but the fact that its all in one place makes the difference!

If any other patches appear meanwhile I’ll try to keep it up to date, in order every single one of you desperate protectors in a crusade to find the builds have a nice place to go… and reliable!!!

Thanks David!!

Exchange Recipients have changed a quite a bit since Exchange Server 2003. With this post I will try to give you an overview of how it works now and eventually a few tips regarding troubleshooting.

Recipient Management

One thing that definitely will make Exchange Administrators life easier is the Recipient Configuration container as it brings such a simplified recipient provisioning for them, such asthe fact that we can split permissions in a single forest, or by other words we have the ability to delegate recipient management to a lower level Administrator as in we will not need to give unnecessary permissions to someone that should just deal with Recipients Management; other ability is we can now create Active Directory objects and mail or mailbox enable them without the need to use Active Directory Users and Computers.

We have improved a lot in terms of scoping as we can now choose between Domain or Forest scoping which basically will allow the Administrator to see only the objects relevant to him, and it can go down to a Organizational Unit level.

Finally seems that Exchange Server was the clear distinctions software starting on the server roles and yes, even here on Recipient Management. We now have very clear and distinct recipient types such as User Mailbox, Room Mailbox, Equipment Mailbox, Linked Mailbox and Shared Mailbox.

There is no longer a need to wait for a recipient to be populated or stamped from Recipient Update Service. Once a user is created from the Exchange Management Console or the Exchange Management Shell, the user is ready to go. If you use the Exchange Management Console for this task, the Edit Email Address Policy wizard will guide you through the process of editing and applying the policy. If you use the Exchange Management Shell, you will use the Set-EmailAddressPolicy cmdlet to edit the policy settings and the Update-EmailAddressPolicy to apply the policy to the intended recipients.

The policy is created with the mailbox now, and once it's created it takes effect immediately for users. For a recipient to receive or send email messages, the recipient must have an email address. Email Address Policies generate the primary and secondary email addresses for your recipients (which include users, contacts, and groups) so they can receive and send e-mail. By default, Microsoft Exchange contains an Email Address Policy that specifies the recipient's alias as the local part of the email address and uses the default accepted domain. The local part of an e-mail address is the name that appears before the at sign (@). For Email Address Policies, you define how the recipients' e-mail addresses will display. For example, you may want to have all of your e-mail addresses display as firstname.lastname@domain.com. In Exchange Server 2007, recipient policies (which were part of Exchange Server 2003) are divided into two separate features: accepted domains and email address policies.

Working With Recipients

In Exchange Server 2007, recipients are comprised of mailbox users, mail-enabled users, mail contacts, distribution groups, security groups, dynamic distribution groups and mail-enabled public folders. In previous versions of Exchange Server, you performed recipient management tasks in Active Directory Users and Computers. You can actually now create Active Directory user accounts from within the Exchange Management Console or Exchange Management Shell when these are mail or mailbox enabled. However, although you can perform all recipient management tasks in the Exchange Management Shell, only some are performed in the Exchange Management Console.

Working With Recipients And Active Directory Users And Computers

Have you ever asked yourself if having Exchange Server 2003 and Exchange Server 2007 in your Exchange Organization and using Active Directory Users and Computers extensions from Exchange Server 2003 to create a mailbox in an Exchange Server 2007 database, would work?

Answer is quite simple... or not. We do not have any way to block creating mailboxes on Exchange Server 2007 from Exchange Server 2007 Active Directory Users and Computers extensions, but it is not supported. There are negative consequences to doing this for the mailbox – principally that Exchange Server 2007 will see this mailbox as a “legacy” mailbox rather than a true Exchange Server 2007 mailbox and that will block various Exchange Server 2007 actions and properties from being edited.

To retrieve and fix all mailboxes wrongly set on the Exchange Server 2007 we need to run the Set-Mailbox -ApplyMandatoryProperties cmdlet. That parameter applies the mandatory properties to the "legacy" mailbox, such as version and type metadata associated with the mailbox. When you apply it a few steps happen:

1. Check whether the mailbox is hosted on Exchange Server 2007 by verifying its ServerLegacyDN (by the prefix “/o=<OrganizationName>/ou=<DefaultAdministrativeGroupName>/”);
2. If it is, we do both of the following things: the ExchangeVersion value is changed to Exchange Server 2007, "0.1 (8.0.535.0)"; the RecipientTypeDetails/RecipientDisplayType is updated according the value of “IsResource/IsLinked/IsShared”;
3. Otherwise, we error out to tell that the task cannot do it because it is hosted on legacy server;

The end result is that the mailbox will have its ExchangeVersion, RecipientTypeDetails, and RecipientDisplayType updated to match reality. When you create a mailbox through Exchange Server 2007 tools, all this process happens automatically. When you create an Exchange Server 2003 mailbox with Exchange Server 2003 tools and move it to Exchange Server 2007, it still happens automatically. However, if you create an Exchange Server 2007 mailbox using the Exchange Server 2003 Active Directory Users and Computers extensions, it will not happen automatically. Run this cmdlet against a mailbox where it's already been run will just reset the values to the same (correct, and presumably current) value, so no problem at all.

Scoping

The default scope for the admin session (whether in the Exchange Management Console or Exchange Management Shell) is what's called Domain Scope. This means that your admin session is configured to talk to a Domain Controler (not to the Global Catalog port, even if it's also a Global Catalog). And it means that your reads/writes will only operate within this Domain's Domain Controlers. This is pretty much how Active Directory Users and Computers snap-in handled scope too. Scope for the admin session only applies to first class objects. If I do Get-Mailbox cmdlet while I'm in Domain Scope, I'll only get back mailboxes (the first class object requested) for the current Domain Scope.

The Forest Scope is a little different. When you're in Forest Scope, the admin session talks to a Global Catalog for all reads (to get the whole Forest view), but does any writes back to a Domain Controller in the appropriate Domain. This is great because it means it's possible to get a view of all mailboxes in the whole Forest, for instance. But it's also bad, because when you're in this mode, replication latency can make things in your view be out of date - since you're reading from a Global Catalog and writing to a Domain Controller in the object's Domain, it's quite possible you won't read the latest data if it has just been changed. So, short version - Forest Scope is great because it lets you see a unified, Forest wide view. But beware of replication latency in some cases.

Administrators can control the scope of recipients shown to be the whole Forest, a whole Domain, or by Organizational Unit within a Domain by using the Modify Recipient Scope context menu of the Recipient Configuration node. Setting your scope controls which recipient objects will be displayed in the Graphic User Interface result panes and also controls which recipient objects will be found by the Graphical User Interface pickers in many cases. For instance, if you configure your scope to be a particular Organizational Unit, then you will only be able to specify this Organizational Unit or one of its children as the target of a new mailbox creation and you will only be able to select a user from this Organizational Unit or one of its children while enabling a mailbox. This can help to reduce the size of the result set you have to filter through while doing administrative tasks if your tasks are easily scoped to a particular part of the directory. In the Active Directory Users and Computers you see objects only under an Organizational Unit Scope, while Exchange Server 2007 Recipient Management allows you to define your scope to be an Organizational Unit, Domain, or even Forest wide increasing administrative flexibility.

$AdminSessionADSettings is a variable exposed by the Exchange Management Shell to allow you to control a number of aspects of the admin session:

1. ViewEntireForest is a boolean (set with $true or $false) that controls whether we're in Forest Scope ($true) or Domain Scope ($false);
2. DefaultScope is the path you're scoped to (i.e. domain.com, domain.com/users, domain.com/users/department). It's ignored if you're in Forest Scope;
3. PreferredGlobalCatalog is how you can hardcode a Global Catalog server to be used for anything that requires it (Forest Scope, and also doing resolution of any global objects you're referencing in the admin session);
4. ConfigurationDomainController is how you can hardcode a configuration Domain Controller;
5. PreferredDomainControllers is how you can configure one (or more) Domain Controllers to be used by the admin session any time as it is required (Domain Scope, or writes while in Forest Scope). This is a multivalued entry, so you can add more than one. If you need a Domain Controler for a Domain where there isn't Domain Controllers specified here, Active Directory Driver will go find one automatically and ignore this list;

The easiest way to manipulate this variable is just like you'd manipulate any other variable. Here's a syntax example:

[PS] C:\Documents and Settings\Administrator>$AdminSessionADSettings.ViewEntireForest = $true

[PS] C:\Documents and Settings\Administrator>$AdminSessionADSettings

ViewEntireForest: True
DefaultScope:
PreferredGlobalCatalog:
ConfigurationDomainController: server1.domain.com
PreferredDomainControllers: {}

Enable/Disable vs New/Remove

In Exchange Server 2007 each mailbox consists of an Active Directory user and the mailbox data that is stored in the Exchange mailbox database. All configuration data for a mailbox is stored in the Exchange attributes of the Active Directory user object. The mailbox database contains the mail data that is in the mailbox associated with the user account. Any of these operations can be done either on Exchange Management Console or Exchange Management Shell.

The Enable and Disable tasks are used against existing objects to remove attributes. When you enable, Enable-Mailbox, a mailbox you are adding Exchange attributes to an existent Active Directory object - mail or mailbox enable. When you disable, Disable-Mailbox, you remove those atributes leaving the mailbox orphan during the retention period after which it will be purged.

The New and Remove tasks need to have windows Account Operator permissions, otherwise the task will fail when trying to perform. Those tasks act directly on the Active Directory objects - mail or mailbox enable. When you create a mailbox, New-Mailbox, you will create a user on the Active Directory and respective mailbox if mailbox enabled or respective external SMTP address if mail enabled. When you remove a mailbox, Remove-Mailbox, you will be actually removing the Active Directory user and leave the mailbox orphan during the retention period, or you can actually through the Remove-Mailbox -Permanent cmdlet purge it with immediately efects. This last operation can only be done through Exchange Management Shell.

Last but not least we have the cmdlet Connect-Mailbox. Use it to connect a disconnected (disabled/removed) mailbox to an Active Directory object. Make sure that mailboxes have been used before at least once otherwise you will not see them here at all.

Email Address Policies

By default, Exchange contains an Email Address Policy for every mail or mailbox enabled user. This default policy specifies the recipient's alias as the local part of the email address and uses the default accepted domain. The local part of an e-mail address is the name that appears before the at sign (@). However you can change how your recipients' email addresses will display. For example, you can specify that your recipients' email addresses display as firstname.lastname@domain.com. Furthermore, if you want to specify additional email addresses for all recipients or just a subset, you can modify the default policy or create additional policies. In Exchange Server 2007, each time a recipient object is modified and saved, Exchange Server 2007 enforces the correct application of the email address criteria and settings. When an Email Address Policy is modified and saved, all associated recipients are updated with the change. In addition, if a recipient object is modified, that recipient's Email Address Policy membership is re-evaluated and enforced.

Exchange Server 2007 brings already some Pre-Canned filters to be used on the creation of Email Address Policies:

• State or Province - Select this check box if you want the Email Address Policy to only include recipients from specific states or provinces. This information is contained on the Address and Phone tab in the recipient's properties;
• Department - Select this check box if you want the Email Address Policy to include only recipients in specific departments. This information is contained on the Organization tab in the recipient's properties;
• Company - Select this check box if you want the Email Address Policy to include only recipients in specific companies. This information is contained on the Organization tab in the recipient's properties.
• Custom - Select this check box if you want the Email Address Policy to include only recipients in specific customized fields you have defined in your users' information. This information is contained on the Organization tab in the recipient's properties. This information will be visible on the Exchange Management Console, however to be edited you need to use Exchange Management Shell.

In addition Email Address Policies once created have to be applied to a set of users, but don’t have to be applied at that very moment. A schedule in the Exchange Management Console allows the Administrator to have the Email Address Policy to take effect after business hours. Exchange Server 2007 has eliminated the asynchronous behavior of the Exchange Server 2003 Recipient Update Service in favor of a more predictable and synchronous provisioning process. Use the Update-AddressList and Update-EmailAddressPolicy Exchange Management Shell cmdlets. To replace the full functionality of Recipient Update Service, you can schedule these Exchange Management Shell cmdlets by using the Task Scheduler in Windows Server 2003.

Mailbox Manager functionality has been separated from Email Address Policies as in Recipient Policies used to be all in one. It has been replaced by Messaging Records Management functionality.

There has been one too many conversations about Data Protection Manager and The Cloud… Some of them correct and others eventually a little bit less correct, so I decide to write this post in order to clear things a bit and hopefully help someone with it.

So apart from being able to protect to disk, tape and disk to disk to tape we can actually protect our information online, now how can we do that?

We have basically two great partners who have been with us on this, and they are Iron Mountain who provide us CloudRecovery solution and I365 who provide us a brilliant solution called EVault (DPM):

CloudRecovery

The new release of Iron Mountain, CloudRecovery, will provide support for DPM 2010 in addition to continued support for DPM 2007 with Service Pack 1. To support rapid corporate data growth, the solution also provides increased scalability – protecting multi-terabyte servers.

“We need to have systems that are always on, and always available.  This is especially true when it comes to the backup and recovery needs of our Microsoft applications – including Exchange, SQL, and SharePoint,” said Alan Bourassa, CIO, Empire CLS. “The seamless integration between Microsoft DPM and Iron Mountain CloudRecovery is ideal for addressing these requirements and we are looking forward to taking advantage of the new features that will be available with the new release.”

EVault (DPM)

EVault (DPM) is an all-in-one backup and recovery appliance for Microsoft centric, mixed computing environments. And besides that believe-it or not even to non Microsoft Platforms… all in the same box!!!

It integrates with your Microsoft business applications and offers the most up-to-date protection for your Microsoft systems. You also gain broad non-Microsoft system protection; optimized cloud connectivity for fast, secure, affordable offsite disaster recovery; and the simple deployment and maintenance of an all-in-one appliance.

Jason Buffington, recently blogged about the DPM 2010 release and the i365 partnership.

So basically these are the solutions we have with these two brilliant partners, and that should be what is considered to be recommended, any further information until today’s date may not be absolutely true…

It was recently published an amazing article about DPM licensing… So many customers come to me asking me all of these questions regarding licensing, and because on my role we don’t deal with that we always end up kind of passing the question to other people in Microsoft…

With this article from the so well known Jason Buffington my life and others is easier now on these tricky subjects…

A small summary is here, however if you want to know the full story please visit Jason’s Article:

If you already have ECAL, then you already have the Client licenses for DPM 2010 and can begin protecting your Windows client machines (and probably not have to renew whatever third-party backup software is currently backing up your workstations).

If you already have the System Center SMSE or SMSD suites, then you can protect your Windows application, file and virtualization servers because you already own Enterprise licenses for DPM. See money saving note above.

And if you are a midsized organization that has been excitedly looking forward to SC Essentials 2010, then you will soon be able to purchase the SC Essentials Plus suites for both your clients and your servers.

I hope this was helpful…

Howdy Protectors,

For those of you with DPM 2012 who have attempted to restore the DPMDB, the restore operation may fails with the following error message:

Error ID: 470
DPM database is not present in the instance of SQL Server. Check that the DPM database is present in the given instance of SQL Server.
Detailed Error: Invalid object name 'dpmdb.dbo.sysfiles'.

In order to fix this please check:

KB2968666 - "Error ID: 470" when you run the dpmsync -restoredb command in Data Protection Manager 2012 http://support.microsoft.com/kb/2968666

Keep Safe!!!

Best Practices Analyzer (BPA) is a server management tool that is available in Windows Server 2008 R2. BPA reports best practice violations to the administrator after BPA scans the roles that are installed on Windows Server 2008 R2. Administrators can filter out unnecessary information or exclude results from BPA reports. Administrators can also perform BPA tasks with either the Server Manager GUI, or Windows PowerShell cmdlets. For more information about Best Practices Analyzer and scans, see the Best Practices Analyzer Help.

When you select the entry for Hyper-V under the Roles node you should see a new section called Best Practice Analyzer:

Here you can select to scan the Hyper-V role and see how you are going against common best practices. One other neat feature of the Best Practice Analyzer is the ability to exclude results.  This way you can remove best practices that you do not believe apply to your environment – so you will not have to deal with a large number of unnecessary errors / warnings.

Another great achievement on the Exchange Universe… Exchange Server 2007 Service Pack 3!!!!

I am very pleased to let you all know that Exchange Server 2007 SP3 is available for download. As we highlighted in Updates to the Exchange Supportability Matrix this past November, this third service pack for Exchange 2007 enables Exchange 2007 to be installed on the Windows Server 2008 R2 version of the operating system. We heard you loud and clear that this is enormously important to our Exchange 2007 customers, so we worked quickly to deliver SP3 in order to meet this requirement.

Download Exchange 2007 SP3 here…

Keep the feedback coming and for those of you evaluating all the good stuff packed into Exchange Server 2010, don't miss the beta of Exchange Server 2010 SP1. You can read about SP1 here…

Kevin Allison
General Manager - Exchange Customer Experience

Imagine the following scenario where you have your Exchange Organization split in three major sites, where each site has their own domain, for instance EMEA, APAC and AMERICAS.

In each site we have CCR clusters, Hub Transport and CAS servers, all in Service Pack 1. Service Pack 2 meanwhile is released and we end up with a major doubt regarding how should we act in terms of such upgrade.

The doubt generally resides between:

• Upgrade each site, every single role, to Service Pack 2 and only then upgrade the other sites, one by one;
• Upgrade all the CAS servers followed by the Hub Transport servers in every single site to Service Pack 2 and only then upgrade the CCR clusters;

The answer for this is quite simple, long maybe as we need to reassure some stuff around it, but definitely it is not hard as it may initially seem.

It doesn’t matter which choice we take, as long as we upgrade first the CAS servers, especially if we are using CAS-CAS proxy. We can have servers with Service Pack 1 and others with Service Pack 2, as long as the CAS is greater (or equal) to the mailbox. In terms of delays, as in timeframe for the patching operation between the first and last patches, that doesn’t really matter, as far as the versions are supported and in this case Service Pack 1  is still supported!

Another thing to take as a recommendation is that two CAS servers can have different versions as far as we do not have them in NLB or even in a CAS Array as in that case the RPC Client Access attribute in the databases will just be a virtual name, as so everything within that virtual name (NLB or CAS Array) need to be consistent in terms of versions… This exclude the time that takes the update of all servers in the NLB or CAS Array obviously.

This apply to all builds, or at least to all the Release Updates and Service Packs supported at the moment. Obviously the CAS servers on the internet facing site must always be the first servers to upgrade, otherwise you definitely break the OWA.

Finally if you upgrade a whole site first, if it is the internet-facing site, there is no issue in having the others sites with lower versions.

If you are concerned on knowing exactly what you need to do in order to migrate your current Exchange environment to Exchange Server 2010, whatever reason it is (multiple firewall rules, multiple certificates, multiple external URLs/ports for clients) don’t be as there is good news. We completely understand that this complexity means there is opportunity for making mistakes, which causes deployments to stall-not to mention a lot of frustration.

The solution is Exchange Server 2010 Deployment Assistant!!!

It will allows you to create Exchange Server 2010 On-Premises deployment instructions that are customized to your environment and all of your specific situations. It starts by collecting some information from you, and based on a your answers, it provides a finite set of instructions that are designed to get you up and running on Exchange Server 2010.

Main idea is to avoid the infinite information you can find in Internet specially in Exchange Server 2010 library and go straight to what you need to do.

Here is a screenshot from the tool, after the initial set of questions were answered and instructions generated.

Happy Exchange Server 2010 Migration!!!

As we heard on the 19th of April we finally released DPM 2010 RTM, however customer wise it will only be available in June…

For our customers which have already in place previous versions of DPM the main question will be how can they migrate their system.

A great utility we came up with was the DPM 2010 Upgrade Advisor. It is an Excel spreadsheet where you can fill in what version that you are coming from and what version that you want to go to as well as what you are using for Disaster Recovery, Tape Library Sharing, etc. And it outputs a checklist to walk you through the upgrade process.

Howdy Protectors,

You may say, here it comes another agent deployment troubleshooting idea, and you’d be absolutely right! In this case is specifically developed for the error 319:

Install protection agent on name.domain.com failed:
Error 319: The agent operation failed because of a communication error with the DPM Agent Coordinator service on name.domain.com.
Error details: The RPC server is unavailable (0x800706BA)
Recommended action: 1) Verify that name.domain.com is remotely accessible from the DPM server.
2) If a firewall is enabled on name.domain.com, make sure that it is not blocking requests from the DPM server. Refer to the DPM Deployment Guide for more information on configuring the firewall for DPM.

Additionally, the DPM-Alerts event log displays the following event:

Log Name: DPM Alerts
Source: DPM-EM
Date: <date>
Event ID: 370
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: name.domain.com
Description:
Agent operation failed. (ID: 370)
The agent operation failed because of a communication error with the DPM Agent Coordinator service on name.domain.com. (ID: 319)

In order to fix this please check:

KB2981833 - System Center 2012 Data Protection Manager agent installation fails with error 319 (http://support.microsoft.com/kb/2981833)

Keep Safe!!!

Howdy Protectors,

It seems Microsoft has released another couple of updates for our beloved product:

2966012 - Update Rollup 7 for System Center 2012 Data Protection Manager SP1

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

2966014 - Update Rollup 3 for System Center 2012 R2 Data Protection Manager

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

Keep Safe!!!

Many thanks to Mark Sewell for this information.

Experience from the field has shown that the following best practices, hints and tips are useful in using JetStress to determine appropriate requirements and configuration. The download location for JetStress and other tools for Exchange 2007 can be found on this page: http://technet.microsoft.com/en-us/exchange/bb330849.aspx.

1. Follow the installed and online JetStress documentation carefully, paying particular attention to the storage subsystem requirements and configuration. Any design for carving out LUNs will need to balance the requirements for performance, recovery time and administrative costs (complexity). Use the Storage Requirements calculator provided:
• List of JetStress updates: http://msexchangeteam.com/archive/2007/07/05/445802.aspx
• Updated blog post: http://msexchangeteam.com/archive/2007/01/15/432207.aspx
• Updated download: http://msexchangeteam.com/files/12/attachments/entry438481.aspx
2. Storage Calculator assumes IOPS values for 80% disk capacity. Latest version makes this explicit. Performance will be less for stripes towards the spindle.
3. Ensure multipathing is in use, if at all possible, in preference to Active-Passive/Concurrent or static routes through the SAN fabric. Check that the multipath software has an active licence if required. Have the customer engage the storage vendor to ensure that there are no bottlenecks through the SAN fabric. There are different algorithms available for multipathing and the vendor can determine which is best for load balancing in the customer's environment.
4. The StorPort driver, introduced in Windows Server 2003, is much preferred over the older iSCSI and can deliver significantly better performance in hardware RAID and SAN environments.
5. Remove anti-virus software and all other non-essential applications, as far as is practical, so that you can take a baseline of JetStress performance. Then you can incrementally add back in required applications and see their effect on JetStress. It is not sufficient to simply disable AV software as the filter drivers will still be in place and could still block or delay file I/O. Management or monitoring software could cause a conflict. Hardware vendors who assist customers in setting up their environment often install such management or monitoring suites. The customer's own OS support team may also install these applications.
6. Also remove any third-party video drivers and verify that only the default VGA driver is installed (which can save a significant number of System PTEs) or use the /BASEVIDEO boot.ini switch.
7. JetStress threads are applied on a per storage group basis. The more storage groups you have, the more I/O you will have with a constant thread count. Use autotuning initially to arrive at an approximate thread count and then fine tune manually to hit the target IOPS for a given number of storage groups. Setting a fixed thread count is not going to provide an exact IOPS value but we are aiming for the actual IOPS to be within 5% of the target. Start with fewer threads and increase them over different tests, using the JetStress reports and Performance Monitor data to confirm that the server and storage are handling the target load. In this way you should arrive at an optimal thread count tuning that provides the best basis consistent JetStress results.
8. Need to view the report in conjunction with the Performance Monitor logs in order to determine that the I/O JetStress is generating is as expected (in terms of I/O sizes, ratios, burstiness, etc.). For example, performance graphs ramping up with time have been seen when using AMD Opteron servers. These turned out to be a missing boot.ini file /usepmtimer switch as per http://support.microsoft.com/kb/895980.

One addition the IO generation in JetStress is linked to the SGs due to the way the IO generation works in the tool. So if you need to add more threads this will generate more IO and spread it over the SGs. It does not mean that the tool gives you the amount of SGs you need! The more SGs you have the better in the Real World!

In this post I will try to bring you the way that all Recipient Lists, such as Address Lists or Distribution Lists behave in Exchange Server 2007 and what should we do with our old ones from Exchange Server 2003 and a few advices to some possible issues you may experience.

Distribution Lists Types

 Most of the distribution lists types that you can get in Exchange Server 2007 are familiar if you have been dealing with Exchange Server 2003 as we can see below:

• Universal Distribution Group: This is the primary type of distribution group you will use for sending messages to large groups of recipients. You cannot assign permissions to this type of group.
• Universal Security Group: You can use this type of group to assign permissions to a group of recipients access permissions to resources in Active Directory and to send messages to all the recipients in the group.
• Non Universal Group: These are groups created in Exchange Server 2003. You will have limited access to them. You should change the scope of the group or create a new one with universal scope so they can become a universal group.
• Dynamic Distribution Group: This type of group doesn’t have a static list of recipients. It uses recipient filters to generate its membership when a message is sent to the group. Every time you will send a message to this group Exchange will query Active Directory. These groups are useful but should be used carefully. Every time a message is sent to these groups you should expect increased processor/disk/network activity.

Howdy,

Microsoft has released an important update to resolve some issues experienced when using the Hybrid Configuration Wizard to create  a new or manage an existing hybrid deployment with Microsoft Exchange Server 2013.

In order to know more about this including a FAQ section please follow the below link:

http://blogs.technet.com/b/exchange/archive/2014/07/30/important-update-available-for-exchange-server-2013-hybrid-deployments.aspx

Keep Safe!!!

Howdy,

The Microsoft Exchange Team just published an amazing document on Office 365 and SPAM. Apparently these will be a series, so we have a lot to look forward on this.

Here is the first one…

http://blogs.technet.com/b/exchange/archive/2014/07/25/spam-email-and-office-365-environment-overview.aspx

Keep Safe!!!

Load balancing serves two primary purposes. It reduces the impact of a single Client Access server failure within one of your Active Directory sites. In addition, load balancing ensures that the load on your Client Access server and Hub Transport computers is evenly distributed.

A great document online has been published regarding Exchange Server 2010 Load Balancing which you can see in the link below, however it is never bad to not forget the requirements of load balancing when we play it in Exchange protocols… http://technet.microsoft.com/en-us/library/ff625248.aspx.

Understanding Load Balancing in Exchange 2010:
http://technet.microsoft.com/en-us/library/ff625247.aspx

We’ve just published a new whitepaper on helping organizations choose Exchange as their voicemail system.  This whitepaper details the value that Exchange 2010's Unified Messaging capabilities offer to empower users, reduce cost and manage risk by replacing a previous voicemail system.

Here are the short and long URLs.  Please use the short one for most scenarios including tweeting or posting:

http://bit.ly/crRISt

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=70cfd1f1-fb01-4abb-a260-41b21ece5839

There are three versions (DOCX, PDF, XPS) available on the site for customers that haven’t quite made the switch to Office 2007/2010 yet.

Hopefully you have already heard about this and have change your deployment plans, otherwise here it goes. Recently it was compared the performance of the Exchange 2010 Client Access role supporting Outlook Anywhere users on both Windows 2008 SP2 and Windows 2008 R2, and found that the improvements the Windows Team has made in R2 more than doubles the number of concurrent users a given server can support, assuming CPU is the limiting resource.

For more information refer to the Microsoft Messaging Team Blog…

These results will be included in an upcoming TechNet whitepaper on Exchange 2010 CAS Guidance.