One of the questions I got in response to my previous article “Customizing Default Role Assignment Policy” is the steps to stop users from updating contact information (like street, city, state, postal code, office, telephone numbers, fax etc) through Exchange Control Panel.

The solution is straightforward and you don’t have to use the Shell, if you don’t want to. Let me explain the process. Login to ECP using an admin account and navigate to Manage My Organization –> Roles & Auditing –> User Roles.

Double click on “Default Role Assignment Policy” to bring up the settings. Uncheck what you don’t want users to do under the “Contact Information” part. Uncheck all boxes if you don’t want users to update anything at all and save the policy.

Next time a user logs in, he/she will have the options to edit been greyed out.

The Exchange Product Group has made a public statement that the issue with EMC & IE9 (read here) has been resolved and a hotfix is available from Microsoft Support. I really don’t understand why the fix is not available for public download. The issue was that you get prompted to close all windows (as shown below) while trying to close the EMC, even when there are no open windows.

In order to install the fix, a released version of IE9 needs to be installed on the machine first. Then:

• MS11-081: Cumulative Security Update for Internet Explorer: October 11, 2011 needs to be installed. This can be obtained from Windows Update or – if you need to download it for local network installation, the packages can be obtained here. The installation of this package is REQUIRED for proper operation of the EMC hotfix.
• In order to obtain the actual hotfix that resolves the interoperability problem with EMC, you will need to call Microsoft support and request a hotfix. The hotfix package is currently not available for public download, but can be obtained from support engineers, who can get it from internal hotfix servers. When you talk to support, the hotfix that you need to request is for the KB 2624899. Please note that this article is not publicly available at this time either.

More info @ source

I was trying to set the OWA mailbox policy that I had created as the default one and to my surprise there is no option to do it, even in the Shell. Let me know if anyone had any joy doing this.

The default behaviour is that even when you only have a single OWA mailbox policy (default), it doesn’t stamp a newly created user with that.

You have to go and set it every time you create a new mailbox. Why Microsoft? It doesn’t make any sense! As most of the users use OWA these days (as it has a great look and feel), everyone needs a standard policy. I can’t think of any reason why Microsoft had skipped a simple option of configuring policy as the default one and making it available to all users by default. Of course you can automate it using the scripting agent, read here

For some reason, you can set an ActiveSync mailbox policy as the default one though! Run the command below in order to set an EAS mailbox policy (named HEW in my case) as the default one.

Set-ActiveSyncMailboxPolicy “HEW” –IsDefaultPolicy $true

Microsoft has released version 17.8 of the Exchange 2010 mailbox server role requirements calculator. It includes enhancements like 3TB disk support and new processor core options.  In addition, there are several bug fixes. 

Check Mailbox Server Role Storage Requirements Calculator updates tracking page to see what has changed.

A blog post explaining how to use the calculator is here and download link for the calculator is here.

I had written about it before, that the Exchange 2010 RTM support ends on Oct 11, 2011 (yesterday), read here. Make sure that you have upgraded all your 2010 servers to SP1 before you log a call with Microsoft support team! Ideally, you should have all the update rollups installed as well (latest being UR5, at the time of writing).

Every exchange admin should be familiar with the screen below by now, if not you should

I was rather surprised to see the error message below while uninstalling Exchange 2010 in my test lab.

The server in question was a member of a DAG, but it had been removed from the DAG gracefully and the DAG was deleted as well. There is no reference to the DAG while I checked the AD configuration using ADSIEdit. There was no cluster in the Failover Cluster Manager as well.

Cleaning up the node from the command line helped Exchange recognize that it is not part of a DAG. The command is cluster.exe node /force.

Retrying the uninstall came back with all green tick boxes.

I came across the error below while decommissioning Exchange 2010 servers in 2003-2010 co-existence environment (test lab). I was trying to remove the arbitration mailbox using Get-Mailbox –Arbitration | Remove-Mailbox –Arbitration –RemoveLastArbitrationMailboxAllowed and got the error below.

The Arbitration Mailbox “mailbox name” is used by Exchange and can’t be removed.

I can see the arbitration mailboxes using Get-Mailbox –Arbitration. I was able to remove one of the system mailboxes using the command above (The screenshot above only has one system mailbox, the other one being removed).

If you are in a multi domain environment, especially with a blank root domain, you need to run Set-ADServerSettings –ViewEntireForest $true before you can list the arbitration mailboxes using Get-Mailbox –Arbitration.

Though I can use ADSIEdit and remove the AD account, I was thinking of removing the Exchange attributes the proper way, using the Shell. I tried disabling the arbitration mailboxes and it worked (surprise). The command I ran was Get-Mailbox –Arbitration | Disable-Mailbox –Arbitration –DisableLastArbitrationMailboxAllowed

I couldn’t remove the mailbox, but I could disable it. Go figure

Microsoft has released Service Pack 2 (SP2) for TMG 2010 Standard and Enterprise editions.

The service pack includes the following new functionality and feature improvements:

New Reports
• The new Site Activity report displays a report showing the data transfer between users and specific websites for any user.

Error Pages
• A new look and feel has been created for error pages.
• Error pages can be more easily customized and can include embedded objects.

Kerberos Authentication
• You can now use Kerberos authentication when you deploy an array using network load balancing (NLB).

To read the release notes, see the Forefront TMG Release Notes (SP2).

Download SP2 here

I have mentioned in my previous article as to how to collapse the DAG networks and configure replication, read here. The correct way as explained in the article is to disable replication on the MAPI network and enable it on the replication network. But, what happens when the replication network fails for some reason? Does Exchange start queuing up the log files?

Exchange Team has thought about it and the way it works is that if the replication network goes down for some reason, Exchange starts using the MAPI network for replication. There are no popups when this happens, maybe an entry is created in the application log. That’s it. As Exchange maintains the flipping of networks for routing replication traffic, things work as normal.

But, what happens if you have disabled replication on the MAPI network as per the article mentioned above? It is a checkbox on the DAG properties to turn it on, but it is not necessary that an exchange admin picks up the failure immediately (he/she should).

Luckily, the algorithm used by Exchange takes care of this situation as well. If the replication network fails for some reason and replication is turned off on the MAPI network, Exchange will still go ahead and use the MAPI network for replication. Even though it is coded to function in this manner, you still need to disable replication on the MAPI network, so that Exchange uses the replication network in the first place.

I got an email today asking whether it is possible to turn off DAC mode once it has been set and if it is possible, the right way of doing it. The sender says that all articles talks about setting the DAC mode, but none says how to switch it off. I must admit that I have been getting a number of emails after I published my contact details here. (Please bear with me guys who haven’t had a response to the emails yet).

To answer the question, yes it is possible to turn the DAC mode off (the default mode). You can turn it back on at any time as well. To understand about how DAC mode works, read my previous article here.

Run the command in Exchange Shell to switch the DAC mode off.

Set-DatabaseAvailabilityGroup “DAG Name” –DatacenterActivationMode Off

To turn it back on, run Set-DatabaseAvailabilityGroup “DAG Name” –DatacenterActivationMode DagOnly

You can check the DAC mode using Get-DatabaseAvailabilityGroup “DAG Name” | fl name, *mode