Multi Tenant - User Profile Sync Issue

Question

Hello

 

I ahve the user profile setup in partition mode. Every thin appears to be installed fine and running. On the main central admin page it list mulitple tenants. I have to seperate subscriptions setup with the following commands

Add-SPSiteSubscriptionProfileConfig -Identity $sub1 -ProfileServiceApplicationProxy $pUPSP -SynchronizationOU $ou -mysitehostlocation $mysiteurl

The subscription also has a featurepack and userauthenticationpath set

 

I recive the foloing erro when the MOS FIM connector tryes to export any user profiles

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.InvalidCastException: Specified cast is not valid.
   at Microsoft.Office.Server.UserProfiles.ProfileChangeData.GetPartitionId(UserProfileApplicationProxy upaProxy)
   at Microsoft.Office.Server.UserProfiles.ProfileImportExportService.UpdateWithProfileChangeData(Int64 importExportId, ProfileChangeData[] profileChangeData)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at Microsoft.Office.Server.WebServiceDirectProxy.WebMethodInfo.Invoke(Object webServiceInstance, Object[] args)
   at Microsoft.Office.Server.WebServiceDirectProxy.Invoke(String methodName, Object[] args)
   at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportDirect.UpdateWithProfileChangeData(Int64 importExportId, ProfileChangeData[] profileChangeData)
   at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportExtension.Microsoft.MetadirectoryServices.IMAExtensibleCallExport.ExportEntry(ModificationType modificationType, String[] changedAttributes, CSEntry csentry)

 

It appears that it is something fo dou do with the Syncornizationou setting. If I select other OU's (not associated with a sunbscription) they seem to export to SP2010 fine and profiles are added to the tenetadmin sites (even if they donot match the syncou setting). The ou is set to the Dn ou=XXX,OU=XXX,dc=xxx,dc=xxx I have seen some exmaple out there just listing the name. I have tried that alos without any success. Here is the steps I have followed. http://blogs.msdn.com/vijgang/archive/2010/05/10/sharepoint-2010-user-profiles-steps-to-partition-the-user-profiles-service-application.aspx

I also added the set-spsitesubscriptionconfig -featurepack -userautehnticationpath

All the sitecollections including the tenetadmin site are in the subscription

 

Any ideas ?

Answer 1

OK

 

After alot of playing around I figured it out

 (sort of)

when adding a subscription to the apartitioned user profile service you are asked to provide a sync ou. This vaule is a string, I assumed it was the DN or x.500 value of the ou. OU=CustomerXYZ,ou=customers,dc=Domain,dc=com. Its not. Its acutally just the name of the last part of the OU, in this exampls CustomerXYZ.

this sucks for two reasons. It doesn't appear to include sub ou's for users and groups and would require the sync ou names to be unique since it doesn't use the full name.

 

anyone else run into this issue ?  It seems kind of weak if this is how they intended to set it up

command

Set-SPSiteSubscriptionProfileConfig -id $20sub -ProfileServiceApplicationProxy $pupsp -SynchronizationOU "CustomerXYZ" -MySiteHostLocation "http://myorbit" -MySiteManagedPath "/personal"

 

 

 

Answer 2

this is by design, and it will work just fine for the "deep" OUs. The lowest level OU name is matched with the paritionid. As long as you don't have OUs with the same name (which would be really stupid anyway) it works just fine.

---

Cheers
Spence
www.harbar.net
Microsoft Certified Master | SharePoint 2007

Answer 3

Thanks Spencer

That’s not the results that I'm seeing. The MOSS MA will not export any users or groups from the sub ou's only the parent specified as the syncronizationou. I opened a case with MS and they mentioned that is a known issue and should be fixed with SP1. That really sucks. I'll update this post when I hear back from him

Also we have a handful of OU' names the same at different levels. That’s one of the benefits of a hierarchical directory such as AD. I think it would work better (in our ace) to specify the whole DN of the OU rather than a subset.

 

 

 

Answer 4

Yes, Export won't work becuase of a DN construction issue. Import works. I agree this should really be a DN anyway for other reasons.

---

Cheers
Spence
www.harbar.net
Microsoft Certified Master | SharePoint 2007

Answer 5

Were you able to getusers and groups to import fine from sub OU's ?

 

I have users at the following levels

 

ou=ABC,ou=Customers,DC=XXX,DC=XXX

OU=Miscusers,ou=ABC,ou=Customers,DC=XXX,DC=XXX

OU=Remote,ou=ABC,ou=Customers,DC=XXX,DC=XXX

 

Setting the syncou to "ABC" only imports users at that level the other two fail with the partion ID error

Answer 6

yeah - i can do an import using OU=ou2, OU=customers, DC=xxx, Dc=xxxx

but you can't have it include sub OUs (of Ou2 in this example). It only works on the one level. this is becuase of the partition id is only mapped to the one OU.

It's one of the key planning aspects of the OU structure for multi-tenant. Not saying i agree with it, just saying it's the way it is :)

---

Cheers
Spence
www.harbar.net
Microsoft Certified Master | SharePoint 2007

Answer 7

Thanks

That really sucks. One ou per subscription realy doesn't scale. I can't believe i'm the only one running into this issue or that it would be hard for them to fix.

 

thanks for your clsrification on this one.

Answer 8

I opened a Case with MS support. They confirmed that this is an issue. They are planing on writing a hot fix and include it with CU2

Answer 9

Hello Kevin

Is CU2 = August Cumulative Update?

Regards

Daniel

Answer 10

Yes, the second CU for SharePoint 2010 is the August CU. This behaviour mentioned above is not changed in this CU.

You must have a "flat" OU structure to make use of the Profile Sync capability with multi-tenant SharePoint 2010 deployments.

 

---

Cheers
Spence
www.harbar.net
Microsoft Certified Master | SharePoint 2010
Microsoft Certified Master | SharePoint 2007

Answer 11

Yeah

 

The developent team canned the fix. This functionality will not be part of the CU2 updates or any future updates. They thought it worked as designed, which is stupid, limiting a single OU for each tenant doesn't scale well. We ended up writing our own Sharepoint Extensible MA

Answer 12

this design doesn't actualy impact scalability at all, it does however restrict you in terms of flexibility. significantly so.

There are many use cases which need to be considered when using nested OUs. If you are taking care of those, and the AD is managed properly, then life is good. However from a supportability perspective, the complixity of some of these considerations could easily break the concept of "isolation".

---

Cheers
Spence
www.harbar.net
Microsoft Certified Master | SharePoint 2010
Microsoft Certified Master | SharePoint 2007

Answer 13

We host more that just Sharepoint for our customers, Exchange, AD, CRM, GP on and on. One OU for 1000 + users limits what we can do with group policys.  This also contradicts OU design in other MS products hosting guides. AD is a scaliabe LDAP directory with granular security. We have seperate OU's for each customers, the problem arrises when there are multiple sub OU's for each tenat customer. (Fairly common AD design) Multiple offices, different GPO's requitemnets ect. Thats what I mean by scalability limitations, oneOU per teanat for all users, groups and contacts.

 

I just think they were short sighted in their design when thinking abou how ASP's hot thie products

 

Answer 14

there is no doubt that nested OUs are a common, and often times, "best practice", especially with regards to gpo processing.

and yes, this design approach could be considered a limitation, but there are also very serious considerations that make it an entirely sensible design choice.

it's not a black and white thing at all, it's all about compromise. there are numerous ways a nested OU structure could invalidate the principles of multi-tenancy and result in data leakage.

All products have limitations which must be considered before thier deployment with restrict solution design, should we have greater flexibility here in the future? Absolutely, but for now we have to live with it, or as you have, implement a custom solution to bridge the gap.

---

Cheers
Spence
www.harbar.net
Microsoft Certified Master | SharePoint 2010
Microsoft Certified Master | SharePoint 2007

Answer 15

We're seeing the same problems here. We only neede to split to companies we were setting up SP for, but still, the concept of only keeping all users in a single OU fails the requirement completely. This functionallity is severly limiting, forcing anyone who wants to use partitioned SP farms into flattening down an entire AD structure. For us this was a serious showstopper. I cannot belive MS didn't present this as an option, "recurse the selected OU" would have saved the day for us - instead we had to go with separate farms.

---

roger

Answer 16

Hi,

we are facing the same problem. We read that you have fixed this with writing your own Sharepoint Extensible MA scipt. I was hoping you could share this information with us.

Thanks in advance!

With king regards.