Hi, while having not all users completely migrated from 07 to 10th exchange server and Exchange 2007 provisioning turned on in AD MA I keep getting such errors on changing MSRTCSIP-Line attribute (and not only it) : There is an error in Exch2007Extension AfterExportEntryToCd() function when exporting an object with DN CN=<user>,DC=<domain>. Type: Microsoft.MetadirectoryServices.ExtensionException Message: **** ERROR **** Object is read only because it was created by a future version of Exchange: 0.10 (14.0.100.0). Current supported version is 0.1 (8.0.535.0). **** END ERROR **** Stack Trace: at Exch2007Extension.Exch2007ExtensionClass.AfterExportEntryToCd(Byte[] origAnchor, String origDN, String origDeltaEntryXml, Byte[] newAnchor, String newDN, String failedDeltaEntryXml, String errorMessage) the message resource is present but the message is not found in the string/message table although value is changed in AD correctly, I'm just wondering what AD MA tries to do with a user and why powershell or whatever triggers such an error?

The cmdlets are versioned and you're running Update-Recipient for 2010 against a user who hasn't been moved and thus hasn't had their msExchObjectVersion (sp?) attribute increemnted. Not much you can do other than put up with it until your migration is complete.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Brian, in this case Update-Recipient cmdlet was running against a user who has already migrated to 2010 :) while AD MA has provisioning set up for 2007. the question is really is _why_ AD MA runs Update-Recipient on every user object update even if not needed? such errors appear when exporting department or title changes, SIP-attributes and so on...

Guys, We have the following setup: 2008 R2 domain, Exchange 2010, FIM 2010 2003 R2 domain, Exchange 2007 2003 R2 domain, Exchange 2003, connected with ADC to a Exchange 5.5 environment To be clear, the to be environment is Exchange 2010 in 2008 R2... :) Either way we have FIM 2010 configured with GAL MA's, and what we are seeing is the following: Suppose we have a group on 2010, it will be projected in the MV and then exported as a contact on 2007 Group on 2010 -> MV group -> contact on 2007 msExchVersion -> msExchVersion | 4535486012416 -> msExchVersion Suppose we have a contact on 2010, it will be projected in the MV and then exported as a contact on 2007 Contact on 2010 -> MV contact_2010 -> contact on 2007 msExchVersion -> msExchVersion -> msExchVersion The odd thing is, in the Attribute Flow configuration, the msExchversion for the contact (for the group) is hardcoded, while the msExchVersion for contact (for the contact) is an direct export of the imported value from 2010 The problem: we are seeing the same error: Object is read only because it was created by a future version of Exchange: 0.10 (14.0.100.0). Current supported version is 0.1 (8.0.535.0). My question: is there any particular reason for the difference? Why not flow the hardcoded version in both cases?http://setspn.blogspot.com

Sorry, Thomas - I don't have AD GAL MAs. I do only import of contacts and public folders to MV and do not care about msExchVersion. so, if you have a hardcoded value in AD GAL MA why don't you try to switch to AD DS MA and manage only contacts objects with it?

The GAL MA's work really neat and we definately will continue working with them. "Hardcoded" was perhaps a bad choice, it's configured in the attribute flows, but I'm really wonder why it was configured in a different way... So I hope someone with more insight as how the GAL MA's work can help us out here.http://setspn.blogspot.com

I haven't seen GAL MA's settings, but if you have to choose the exchage server version from the dropdown list then it's obvious - FIM will either do nothing after export, or run update-recepient cmdlet localy, or run it on exchange server using RPS. So GAL MA should export one of the 3 hardcoded values I suppose.

I haven't seen GAL MA's settings, but if you have to choose the exchage server version from the dropdown list then it's obvious - FIM will either do nothing after export, or run update-recepient cmdlet localy, or run it on exchange server using RPS. So GAL MA should export one of the 3 hardcoded values I suppose.