Knowledge Partner
Knowledge Partner
295 views

AD driver, Entitlements, ExchangeMailbox Q

So IDM 4, packaged driver.

Sub-Command, NOVLADENTEX-sub-ctp-EntitlementsImpl

For modify events:

If entitlements are in use, for a user, and its changing, does two loops.

For each Removed Entitlement
For Each added entitlement.

All these do is touch the homeMDB, and add or remove them as needed,
thus triggering the Ex2007/2010/2003 mailbox creation or removal as needed.

Notice, no mailNickName set into AD.

Now for the add case, the Sub-Create detects that Entitlements are being
used, there is one set at create time, and therefore sets an op-prop to
so indicate.

ITP, NOVLADENTEX-itp-EntitlementsImpl,

if the GCV is right, if its an <add-association> event, if the op-prop
is set, and the entitlement (ExchangeMailbox) is available, then one loop.

For Each Entitlement, ExchangeMailbox
Inside the loop it sets 2 (!) attrs, homeMDB as in the Sub-Command, but
also mailNickName.

Is this on purpose? A mistake? Needed in either, both, or none of the
cases?

Labels (1)
0 Likes
3 Replies
Knowledge Partner
Knowledge Partner

Re: AD driver, Entitlements, ExchangeMailbox Q


Probobly on purpose since we don't know what attribute to use for
nickname.
Default it uses sourcename so one way would be to handle it on
renames.
Better woud be to have a second gcv with the attribute to use for
nickname and trigger on change of that.

Any other ideas?


--
-----------------------------------
joakim . ganse_@_ accept-it . se
------------------------------------------------------------------------
joakim_ganse's Profile: http://forums.novell.com/member.php?userid=6236
View this thread: http://forums.novell.com/showthread.php?t=451959

0 Likes
Knowledge Partner
Knowledge Partner

Re: AD driver, Entitlements, ExchangeMailbox Q

On 08.02.2012 09:26, joakim ganse wrote:
>
> Probobly on purpose since we don't know what attribute to use for
> nickname.
> Default it uses sourcename so one way would be to handle it on
> renames.
> Better woud be to have a second gcv with the attribute to use for
> nickname and trigger on change of that.


It's really not a good idea to set the mailNickname to follow the AD CN
as the AD CN only needs to be unique in an OU.

Best practice is that mailNickname should be unique (to the domain)- as
there are some scenarios where uniqueness is required - ref.
http://technet.microsoft.com/en-us/library/cc539081.aspx
Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Knowledge Partner
Knowledge Partner

Re: AD driver, Entitlements, ExchangeMailbox Q

On 07.02.2012 23:23, Geoffrey Carman wrote:
> So IDM 4, packaged driver.
>
> Sub-Command, NOVLADENTEX-sub-ctp-EntitlementsImpl
>
> For modify events:
>
> If entitlements are in use, for a user, and its changing, does two loops.
>
> For each Removed Entitlement
> For Each added entitlement.
>
> All these do is touch the homeMDB, and add or remove them as needed,
> thus triggering the Ex2007/2010/2003 mailbox creation or removal as needed.
>
> Notice, no mailNickName set into AD.
>
> Now for the add case, the Sub-Create detects that Entitlements are being
> used, there is one set at create time, and therefore sets an op-prop to
> so indicate.
>
> ITP, NOVLADENTEX-itp-EntitlementsImpl,
>
> if the GCV is right, if its an <add-association> event, if the op-prop
> is set, and the entitlement (ExchangeMailbox) is available, then one loop.
>
> For Each Entitlement, ExchangeMailbox
> Inside the loop it sets 2 (!) attrs, homeMDB as in the Sub-Command, but
> also mailNickName.
>
> Is this on purpose? A mistake? Needed in either, both, or none of the
> cases?


This isn't a bug per-se, but I don't think it's an optimal solution
there are several factors behind this.

1. mailNickName is optional, it is not required by Active Directory on
add or modify. if it's not supplied, AD will by default use the same
value as is set for sAMAccountName.

In the itp, it sets the mailNickname to the source name (CN from AD)
which depending on your GCV choices could be either Full Name or IDV CN.

On an aside, there are some bugs in the regex used here to sanitize the
mailNickname. The primary bug hasn't been fixed yet (despite being
raised a while back). The correct regex should be:
[^a-zA-Z0-9\x21\x23-\x27\x2a\x2b\x2d-\x2f\x3d\x3f\x5e-\x60\x7b-\x7d\x7e\xc0-\xf6\xf8-\xff]

2. Known driver shim bug, now fixed

However there were previously some gotchas with setting mailNickName by
itself. The shim silently ignored mailNickName when it was sent without
homeMDB in the same operation in a add or modify event

This was fixed in IDM 4.0-3.6.1-3.5.1 Active Directory driver version
3.5.13 Patch 6

I think that limitation informed the decision to only set mailNickName
at add (or add-association) in the default policy.

Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.