Setting Default OU For Distribution Groups In Exchange 2010…

As an Exchange administrator, you can set the default OU in which you want all newly created distribution groups to be stored. This may not be appealing for bigger companies, as they tend to have a complex OU structure and there will be more than one OU that holds the distribution groups.

For a smaller organization, this setting might come in handy as all groups will be stored in the correct OU, which keeps the OU structure tidy as well. By default, while creating a distribution group, you are given the option as to where the group has to be stored.

Create distribution group in EMC

We can set the default OU globally by running Set-OrganizationConfig –DistributionGroupDefaultOU “DN of OU”. In my case, I have set to store all groups in an OU called “Groups”, in hew.local/howexchangeworks/groups.

Set default OU for DGs

Next time you create a distribution group, the OU is not filled by default. You are presented with the same wizard as before. Just go ahead and create the group and it will be stored in the right place. As an example, I created a “Test Group”. I didn’t make any OU selection.

Test group creation

After the group was created, I checked my OU and my group was there. All works then!

DG created in default Ou in AD

Setting the default OU didn’t succeed when I issued the command with the name of the group or the full OU path (with and without “”).

Error with other commands

Anyone knows why? I checked the help in PowerShell to see what type of values the “DistributionGroupDefaultOU” takes, but there was no mention of it.

PS Help

Exchange 2010 SP1 Unified Messaging & DAG Members Supported On Hyper-V…

Microsoft have changed their support statement on virtualizing unified messaging role and running DAG members on hypervisor based clustered hosts. The updated statement is summarized below.

  • Unified Messaging server role (2010 SP1) is now supported in a virtualized environment.
  • Combining Exchange 2010 high availability solutions (database availability groups (DAGs)) with hypervisor-based clustering, high availability or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers is now supported.

Microsoft has also released “Best Practices for virtualizing Exchange Server 2010 with Windows Server 2008 Hyper V” whitepaper.

Whitepaper

Download the whitepaper here

Configuring Hierarchical Address Book In Exchange 2010…

Hierarchical Address Book (HAB) is a new feature introduced in Exchange 2010 and only comes into action when Outlook 2010 is used. All of us are used to the traditional address book model. With HAB, users can browse recipients by using Organizational hierarchy. Once properly configured, HAB gives a true picture of the company structure in terms of different departments, who heads different departments etc.

It is not a feature which is useful for all companies. It doesn’t give any added benefit than exposing the hierarchy to the end user, that too only when viewed using Outlook 2010. Implementing HAB needs a full understanding of the company structure. In my lab, I have set up HAB for How Exchange Works for demonstration purpose.

By default, HAB is disabled or not configured. Issuing the command Get-OrganizationConfig | fl hier* will show that the hierarchical address book root is empty. The company hierarchy is configured using distribution groups. Hence, a distribution group has to be created for the root (company name) and every department/branch the company has.

In my lab, How Exchange Works has HR, IT, Marketing and Sales as the main departments. Within IT, there are Exchange Team, Unix Team & Network Team.

First step is to create an OU which will hold all HAB objects. Although it is not mandatory, it keeps the OU structure clean. I have created an OU called “HEW HAB”.

Create OU for HAB

Next, create distribution groups for each of the departments. You can use EMC or Shell. Below screenshot shows the group I have created for the company name (address book root).

Create HEW Distribution Group

After the groups have been created, stamp them as hierarchical group. As I have an OU for HAB objects, it was easy to filter the groups.

Convert all groups to hierarchical

Next, set the HAB root (How Exchange Works in my case) using the command below.

Set-OrganizationConfig –HierarchicalAddressBookRoot “How Exchange Works”

Set HierarchicalAddressBookRoot

If you launch Outlook 2010 and click on “address book” now, you will see a new tab called “Organization” and How Exchange Works listed as the root.

HAB Root in Address Book

Now, the company hierarchy has to be configured by creating the different departments as member of the root group. In my case, I added IT, Sales, Marketing and HR as members of the distribution group “How Exchange Works”. You can use either EMC or Shell.

Next step is to add the different teams into the department groups. In my case, Exchange Team, Unix Team and Network Team were made members of IT. That completed the hierarchy for my lab setup and the address book updated the changes.

All hierarchical groups visible

In order to have users listed under teams/departments, add users as members of the corresponding groups. In my case, I added three accounts into Exchange team. The users get listed in alphabetical order by default.

Full HAB view

That won’t be a true reflection of hierarchy in any company. Hence, in order to list the users in the order of the position they hold within the company, an attribute named “SeniorityIndex” has to be populated. The higher the seniorityindex, higher the priority.

I added seniorityindex to my three accounts using the following command.

Set SeniorityIndex

My address book reflected the changes for sure!

Full HAB with seniorityindex

In a large company, setting up HAB will be a time consuming exercise. It is upto the company to decide whether they have the man power for it and if it is needed at all in the first place!

Changing Help URLs In Exchange 2010…

By default, the Help urls in Exchange 2010 points to help.outlook.com where there isn’t much information regarding on-premise Exchange deployment. Some companies might have their own SharePoint site where help files are located. For example, a company can publish their Helpdesk details in Outlook Web App and Exchange Control Panel so that a user can quickly contact the team if they have any issues.

Similarly in large corporates, Exchange is managed by a number of teams. It will be easier if the help url in the EMC opens up an internal/external site where all information (phone numbers, email, distribution groups etc) regarding different teams are published.

I just came across this option and thought of sharing it. The default values for the help file is exposed by running Set-ExchangeAssistanceConfig in the shell.

Exchange Assistance Config Default

Though there are many options, only ControlPanelHelpURL, ManagementConsoleHelpURL, OWAHelpURL and OWALightHelpURL can be set, as the rest of them are reserved for internal Microsoft use.

Run the following command to change the EMC Help url.

Change console help

This changes the Help URL in EMC.

Help url in EMC 2010

Similarly, run the command below to change the OWAHelpURL and the changes will be reflected the next time you use OWA.

Change owa help

Stripping Internal Exchange Organization Info From NDRs Sent To Remote Domains…

The default “remote domains” setting in Exchange 2010 allows non-delivery reports (NDRs) to be sent to all remote domains. These error message will contain internal Exchange Organization information like the server names, IP addresses, AD domain name etc.

What if you are security conscious and what to strip those information from the NDRs and yet get it sent to external senders? It is possible in Exchange 2010 SP1, with the introduction of a new parameter named “NDRDiagnosticInfoEnabled” for the Set-Domain cmdlet.

By default, the value of “NDRDiagnosticInfoEnabled” is set to $true, which means that external senders will get the full NDR.

Default NDRInfoEnabled

If you want the senders to be notified regarding the error only and withheld any internal Exchange information, set the value of “NDRDiagnosticInfoEnabled” to $false. I am setting this only for my “Default” remote domain, as I am happy with sending the full NDR to my partner company theucguy.net

Set remote domain to strip info from NDR

Next time an NDR goes out to an external sender, it won’t have any inside information Winking smile

Customizing Remote Domain Settings In Exchange 2010…

Remote domains tab in the exchange management console is one that most Exchange administrators skip or pay less attention to. I am not sure whether it is because they don’t know what is possible or are happy with the default values.

Remote domains tab in Exchange 2010 come with a default setting for all remote domains. And the default one is enough for most of the deployments. Some companies might have partners with whom they federate or may have another Exchange organization which they have recently acquired. Whatever be the case, there will be a compelling reason to have a different set of settings for that domain alone. That is where the remote domains tab become useful.

You can create additional remote domains (with the domain name, not *) and have a different set of settings. Maybe you want to allow automatic replies & forwards and want to have rich-text format for all emails with your partner company. I have done exactly that in my lab, a separate set of settings for theucguy.net

Right click in the console and select “New Remote Domain”, fill in the domain name and that’s all it takes to create it.

Create remte domain HEW

Once created, you can change the settings to suit your needs.

Remote domain HEW settings

There is a tab to specify whether the domain is cloud based as well.

Cloud remote domain

Exchange 2010 Management Console And IE9 Issue…

I came across this today! When I try to close the Exchange Management Console (2010 SP1), it brings up the following dialog box and the only way to come out is to kill mmc.exe from the task manager.

“You must close all dialog boxes before you can close Exchange Management Console”

Error while closing EMC 2010

A quick google says that many others are having the same issue and that it happens when the box that has EMC loaded has IE9 as well. I checked my test machine and it had IE9 as well. I uninstalled IE9 and things are fine now. As Microsoft is aware of the issue, there should be an update to fix this issue soon. The workaround is to uninstall IE9 or kill mmc from task manager for the time being.

Anyone else having the same issue? Any other workarounds?

What’s In Exchange 2010 SP2?…

Tony Redmond explains his TEC experience in his blog and he mentions about the updates in Exchange 2010 SP2 that was discussed in the conference. He writes,

**** In terms of what’s next for Exchange, Kevin (Exchange GM) briefly talked about features that will appear in Exchange 2010 SP2 later this year. Three major updates were discussed:

  • Address Book Policies (ABPs), also known as “GAL segmentation”. This feature is described for Exchange 2007 in a white paper but Microsoft knew that the approach taken (ACLs) would break in the Exchange 2010 architecture, which indeed happened in Exchange 2010 SP1. ABPs follow the same route as other policies (OWA, ActiveSync, etc.) applied to mailboxes in that an administrator can create policies that establish what objects in the GAL can be viewed by a user. The default policy is equivalent to today’s GAL – you can see everything. But administrators can narrow things down by establishing policies that might restrict a user to only being able to see GAL objects that belong to a specific department or country and then apply that policy to mailboxes using EMC or PowerShell. In effect, address book policies create virtual views into the GAL that administrators can amend to meet company requirements. See the Exchange team blog for some more information.
  • Device overload: Microsoft acknowledges that it’s difficult for administrators to know how well mobile devices work with Exchange and with the mass of clients that can connect to the server. Recent issues have occurred that caused recurring meetings to be deleted by some clients because of a lack of interoperability testing that might have surfaced the problem. A new ActiveSync testing lab is being established to help improve interoperability between devices produced by different vendors including RIM, Apple, Microsoft, and Android.
  • Hybrid co-existence, aka rich co-existence. Kevin noted that “We do not expect large customers – over 2500 seats – to have everyone in the cloud all at once.”  A hybrid deployment therefore requires the on-premise Exchange organization to be tailored so that it can share data effectively with Office 365. Today, some 46 individual settings have to be changed to make rich co-existence work well. Exchange 2010 SP2 includes a wizard that will reduce the number of settings that require administrator intervention to 6, so the process of establishing co-existence will be much simpler.

Read the full post here

Exclaimer Outlook Photos – And It’s Free…

I have come across a number of customers who want to have staff photos visible in their GAL. They typically look at this feature when migrating from previous versions of Exchange to 2010. Though Microsoft supports this feature with the use of PowerShell, Exclaimer Outlook Photos gives a free GUI tool – not just for you to try, not just for a limited period, not with feature limitations but absolutely free.

The tool can be installed in any domain joined machines – any one from XP to 2008. Check the system requirements here

Exclaimer

Download the tool here

Exchange 2010 DAG Error – A server-side database availability group administrative operation failed. CreateCluster errors may result from incorrectly configured static addresses. The operation failed…

I came across this error while adding the first DAG member to an Exchange 2010 SP1 DAG. The DAG was created successfully, but adding the first server to the DAG resulted in the following error.

Error:
A server-side database availability group administrative operation failed. Error: The operation failed. CreateCluster errors may result from incorrectly configured static addresses. Error: The computer account ‘DAG1′ could not be validated. Access was denied. Check that the current user (NT AUTHORITYSYSTEM) has permissions to create computer accounts in the domain or to claim the computer account. [Server: MBX01.domain.local]

A server-side database availability group administrative operation failed. Error: The computer account ‘DAG1′ could not be validated. Access was denied. Check that the current user (NT AUTHORITYSYSTEM) has permissions to create computer accounts in the domain or to claim the computer account.

DAG Membership Error

I did the following to troubleshoot the issue.

  • As it was complaining about access denied, I checked the account I was using and the necessary permissions were in place.
  • As the error mentioned about incorrectly configured static IPs, I checked the DAG IP and everything was fine.
  • I checked AD to see the permissions on the DAG account (CNO) and to my surprise there was no account with the name DAG1, but Exchange Console created the DAG without errors!

As I was in a rush to get the system up and running, I deleted the DAG, pre-staged the DAG account in AD and gave the first mailbox server full rights on the DAG object and disabled the DAG computer account. Once this was done, DAG creation and member addition went smoothly!