missmiis » Exchange 2010

Provisioning Exch 2010 when you’ve stil got Exch 2007

Carol — Tue, 18 Jan 2011 18:27:06 +0000

At one of my customers we’ve started provisioning all new users directly to Exchange 2010, while the old users are being progressively migrated from Exchange 2007. I modified the provisioning code for Exchange 2010 (basically just adding the msExchHomeServerName attribute as explained in this doc) and new users and mailboxes were created just fine.

What I didn’t expect was that this would break password sync.

When you have the Exchange 2007 or Exchange 2010 provisioning option enabled on the AD MA, the Update-Recipient cmdlet is run after every export – apparently even when the update has nothing to do with mail attributes. When the user is still on Exchange 2007, but you’ve enabled Exchange 2010 provisioning, this cmdlet causes an error. Unfortunately if the AD is also a password sync target the behaviour is worse – it actually crashes the miiserver.exe process!

I have put the following workaround in place until all users are migrated to Exchange 2010:

I’ve left the provisioning code configured for Exchange 2010 provisioning – this populates the necessary attributes.
I’ve set the MA’s Exchange option to “No provisioning”.
I run the following powershell command from a scheduled task to complete the process of creating the mailboxes:

get-user -resultsize unlimited | where {$_.RecipientTypeDetails -eq 'LegacyMailbox'} | update-recipient

Exchange 2010 LoadGen doesn’t work with a CAS Array

Carol — Thu, 21 Oct 2010 15:00:22 +0000

While attempting to use the 64-bit version of LoadGen for some Exchange 2010 testing, I found the tests were failing, and in the LoadGenSim logs were lots of errors like this one:

Microsoft.Mapi.MapiExceptionNetworkError: MapiExceptionNetworkError: Unable to make connection to the server. (hr=0x80040115, ec=-2147221227)

I then noticed that, just above these errors, I had a line which started as follows:

Outlook2003Online Error: 0 : 10/21/2010 15:20:53 -- Diagnostic context (user: 'DOMAIN\CED40A97-LGU000001'): distinguishedName 'CN=CHGVA-EXM11 CED40A97-LGU000001,OU=DBTest2010,OU=2010SERVER,OU=Users,OU=LoadGen Objects,DC=mydomain,DC=com', exchServerDn '/o=Organisation/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=casserver.mydomain.com

The interesting thing was that the specified exchServerDn does not actually exist. The name casserver.mydomain.com was one I had registered in the DNS for the CAS NLB cluster, and there is definitely no server object of that name under the Configuration branch.

As well as creating the NLB cluster I had also defined a CAS Array, and the mail databases had been created after that, meaning they had the array configured in their RpcClientAccessServer setting. Before I could get LoadGen to work I had to reset this setting on my test databases so they specified one particular CAS server, rather than the array.

set-mailboxdatabase DBTest2010 -RpcClientAccessServer PHYSICAL_CAS.mydomain.com

A couple of other observations..

Despite lots of errors in the logs about public folders and free-busy (even if you don’t select “Initialize Public Folder Database”) it seems to work fine without a PF DB on 2010 (and it won’t use one on 2007).
The “Initialize mailboxes” step takes ages to get going. Let it run.
I installed it on a regular Windows 2008R2 server – not an Exchange server.
I don’t know if I’m doing something wrong, but I seem to have let each new test create its own accounts. If I try and use the accounts from a previous test it tells me I didn’t select any mailusers.

A GALSync powershell script

Carol — Sat, 15 May 2010 09:05:18 +0000

Here is a script I wrote to do a simple GAL synchronization between two Exchange organizations. The script finds the mail-enabled users in one domain, and creates contacts for them in the other domain. Existing contacts will also be updated and deleted as needed.

Update

There was a bug in the original script where I had forgotten to populate mailNickname. I have now done so, adding a “c-” to the front of it as a completely optional convention to avoid conflicts.

Update 2

Several people have commented below about needing to enable the contacts in Exchange after creation. I have used the modifcations posted by Mark in the comments to make a new version that I hope will work better with 2007 and 2010, though I have only tested it with 2010. Both versions are linked below, and please keep adding your comments and modifications.

The Script

Now I have two versions the scripts have been moved off to seperate pages. Follow the links below.

Version 2	Added the Update-Recipient command for Exchange 2007 (through local powershell) and Exchange 2010 (through remote powershell).
Version 1	Original version that uses the ActiveDirectory powershell module to create the contact objects.

Other people’s versions

Modified for Distribution Lists: http://www.wapshere.com/missmiis/galsync-v2/galsync-ps1-for-distribution-lists

Group Management Comparison

Carol — Thu, 31 Dec 2009 08:34:11 +0000

Following on from my last post about the overlaps between FIM and Exchange 2010 I wanted to clarify for myself the group management capabilities in FIM, Exchange 2010 and ILM.

Warning: I will have to revisit this post – as I haven’t yet installed Exchange 2010 in a production environment the Exchange comments are based on reading rather than hands-on experience, and in particular I’m unsure about the management of email-enabled Security groups.

Exchange Distribution Groups
	FIM 2010	Exchange 2010	ILM 2007 or FIM Sync
Rules based eg., “All Finance Dept”	Managed and populated in FIM Portal. All users must also be represented in FIM Portal.	Dynamic Distribution Lists	External genarator needed Eg., Group Populator
Manually populated	Managed and populated in FIM Portal. Owner approval workflow, Join and approve in Outlook, Create, join and approve in FIM Portal.	Managed and populated directly in AD Owner approval workflow, Request and approve in Outlook, Create in ECP.	No native functionality to permit manual group popluation. Synchronizes membership lists from one system to another (eg., from a database table to AD).
Other Management	Manage other attributes, eg., who can send to the list, Auto-generate new groups, eg., for a new Department or Location (with Workflow development).	Exchange management tools.	Synchronize any attribute, though it must be generated somewhere outside ILM.
Access Control	Permissions to create, delete, modify granted in FIM Portal only.	Permissions to create, delete, modify granted in AD – though RBAC simplifies.	N/A

Security Groups
	FIM 2010	Exchange 2010	ILM 2007 or FIM Sync
Rules based eg., “All Finance Dept”	Populated and managed in FIM Portal. All users must also be represented in FIM Portal.	N/A	External genarator needed Eg., Group Populator
Manually populated	Managed and populated in FIM Portal. Owner approval workflow, Join and approve in Outlook only if the group has an email address, Create, join and approve in FIM Portal.	Membership management for Security groups with email address? N/A for non-email emabled Security groups.	No native functionality to permit manual group popluation. Synchronizes membership lists from one system to another (eg., from a database table to AD).
Other Management	Replicate the groups to other systems – not just AD, Auto-generate new groups, eg., for a new Department or Location (with Workflow development).	Mail-enable existing AD Security groups using Exchange management tools.	Replicate the groups to other systems – not just AD.
Access Control	Permissions to create, delete, modify granted in FIM Portal only.	N/A	N/A

Is there too much overlap between FIM 2010 and Exchange 2010?

Carol — Fri, 18 Dec 2009 09:33:58 +0000

I’ve been getting myself up to speed on the new feaures of Exchange 2010, and some of them look a little familiar…

The ECP, or Exchange Control Panel, is a web interface where users can perform certain administrative functions such as modifying their own profile and managing Distribution lists they own.
Users can request to join groups which may include an owner-approval workflow.
And finally Role Based Access Control simplifies assigning the right level of permissions – so intead of making someone an organization-wide Exchange administrator, you can grant more finely-grained permissions, and it’s based on roles so it should be simpler to apply.

So, in one swoop, a number of the key features of FIM look less relevant: the FIM user portal for self-management, the distribution list management and workflows, and the MPRs which give access to other user’s attributes. Hmmm.

Of course we get a lot more with FIM, and it’s a generalised platform, as opposed to being targeted specifically at Exchange-enabled objects. Also one can make the argument that it’s more secure to make modfications outside of AD and then sync them across in a controlled way, rather than giving people access directly into AD. And finally FIM gives us password reset…

But considering the expected cost of FIM CALs, how many IT decision makers will look at FIM and decide it doesn’t give them enough over what they’re going to be getting anyway with Exchange 2010?