We've run into a situation where the rangeUpper of the 'department' attribute is too small at 64 characters. I don't believe you can change an attribute that is in use, but I thought I'd ask if anyone had any suggestions. Is there a way to make the rangeUpper value larger on an attribute like 'department?'
I've already considered creating a new department1 attribute but that won't work because department is one of the user attributes that flows to Exchange and its GAL which is where we want the longer values to be displayed. It also occurs to me that it could break Exchange if it assumes that department is only 64 characters. Thus I don't think there is any way to fix this but I thought I'd throw this out there anyway.
The back story: we've just rolled out Workday as our HR system. We are using MIM to sync external SOR data into AD. Workday has this odd notion of concatenating every level of the departmental hierarchy which can result in a compound department name string that is much longer than 64 characters. Worse yet, the most significant bit (the actual name of the user's department) is on the right end, so a simple truncation would cut off the head so to speak. We are considering our options and I'd like to know if modifying AD should even be on the table.
Forum info: http://www.activedir.org
Problems unsubscribing? Email admin@xxxxxxxxxxxxxxxx
modifying the AD schema
- 483 Views
- Last Post 30 June 2017
Eric, I think you nailed it regarding possible downstream risks of changing the schema even if you could find a way to change the schema.
My suggestion here would be to work this along the Workday/Azure AD/provisioning angle instead. MS is VERY interested in ensuring that "two way" provisioning scenarios from key SaaS providers works cleanly and it seems to me that the MS product group would understand this issue and be willing to work with Workday to have them address this. Do you have a channel to escalate that?
Things may have changed since my day, but back when I was young you could totally change the limits on an existing attribute. We put in a bunch of code to make this work. Replication should work just fine, and applications are supposed to read schema info at run time, not permanently hard code it during development. The one issue I can imagine with Exchange is that the longer department names might not fit cleanly in the details dialogs that Outlook displays. However, the “display templates” for those are stored in the directory and are editable – just make the field longer as needed. You can also edit the display templates to expose new fields if you want. OWA is a mystery to me, but hopefully it did not drop the ball here. If Exchange server itself has lost the ability to follow schema changes I will personally rise from the dead and go haunt the dev team until they fix it. DonH
Thanks Don, I remember the Win2k days when the computing landscape was relatively simple.
First, I can’t trust that the Exchange team will do the right thing because they have consistently done bizarre things. Have you seen how many attributes get
added to mail-enablable objects when the latest Exchange LDIFs are applied? There are more Exchange attributes than all others combined and most appear to go unused. It must be a rite-of-passage for each new Exchange dev to add one or more AD attributes! “Look,
I have my very own OID!”
Then there are all of the intermediate pieces in place for Office 365 and Exchange Online: DirSync/AAD-Connect to get the AD bits to Azure AD, Azure AD itself
which does not allow changes to the existing schema objects, then an internal O365 synchronization process to get the AAD objects over to EO. And I don’t know if or how Exchange Online exposes the Outlook UI display templates even if the department data would
arrive at EO unmolested.
I might open a Premier Support request just to see how far I can get with this. Another option is limiting the length of the data field in Workday. I have internal
contacts here working with Workday who could probably help.
Exchange on-premises still supports schema changes and respects changes to the Details Templates, and Outlook still uses the Details Templates when connecting
to an on-premises Exchange server.
When it comes to EOL? I doubt it very highly.
As with Don, I have no idea about OWA. I haven’t tested it in a long time.
As far as all those other attributes, the shadow attributes are used to ensure that there are no conflicts between on-premises and O365 AD. I don’t think they
are replicated in Azure AD.