Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
Anonymous_User Absent Member.
Absent Member.
461 views

Office 365 Driver: Attribute Re-Mapping for Email Address


Could anybody give me an idea on how to map the identity vault attribute
Internet Email Address to the Primary E-mail address of a user? I guess
that is one of the SMTP aliases. Out of the box the driver maps the
Internet Email Address to the Alternate E-mail address of a user.
Unfortunately I am going to have to do something different from that.

I don't have any experience with this driver, and I am just now starting
to use it and the powershell commands to manage the tenant. I know that
using powershell commands I have to go into the Exchange account
configuration properties of a user to set the windows e-mail address
property.

In powershell I am doing something like this:

$credential = Get-Credential

$session = New-PSSession -ConfigurationName Microsoft.Exchange
-ConnectionUri https://ps.protection.outlook.com/powershell-liveid/
-Credential $credential -Authentication Basic -AllowRedirection

and then the value assigned to that variable $session is used with

Import-Session $session.

After that I run the following command

set-mailbox -identity $upn -WindowsEmailAddress $emailAddress

Does that make sense to anybody?


--
celsolima
------------------------------------------------------------------------
celsolima's Profile: https://forums.netiq.com/member.php?userid=260
View this thread: https://forums.netiq.com/showthread.php?t=52191

Labels (1)
0 Likes
10 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Office 365 Driver: Attribute Re-Mapping for Email Address

On Thu, 13 Nov 2014 23:38:33 +0000, celsolima wrote:

> Could anybody give me an idea on how to map the identity vault attribute
> Internet Email Address to the Primary E-mail address of a user?


"Primary" email address is an Exchange thing. It defaults to using the
userPrincipalName of the object you created in Azure AD, which is what
the Office365 driver actually talks to, via the msol-* commandlets.

If you need something other than UPN, in Exchange, you use the get-
mailbox commandlet to get the current array of email address values, then
add your "primary" address to the array, with the "SMTP:" prefix, then
use set-mailbox to set the email address with the array values. Whichever
value has prefix "SMTP:" is "primary", any other "smtp:" values in the
array are also valid, but are not "primary".

Ugly? Yep.


> I guess
> that is one of the SMTP aliases. Out of the box the driver maps the
> Internet Email Address to the Alternate E-mail address of a user.


Yeah. That doesn't seem to accomplish anything.


> Unfortunately I am going to have to do something different from that.


;-(


> I don't have any experience with this driver, and I am just now starting
> to use it and the powershell commands to manage the tenant. I know that
> using powershell commands I have to go into the Exchange account
> configuration properties of a user to set the windows e-mail address
> property.
>
> In powershell I am doing something like this:
>
> $credential = Get-Credential
>
> $session = New-PSSession -ConfigurationName Microsoft.Exchange
> -ConnectionUri https://ps.protection.outlook.com/powershell-liveid/
> -Credential $credential -Authentication Basic -AllowRedirection
>
> and then the value assigned to that variable $session is used with
>
> Import-Session $session.
>
> After that I run the following command
>
> set-mailbox -identity $upn -WindowsEmailAddress $emailAddress
>
> Does that make sense to anybody?


Makes complete sense. Sadly, you can't do that. So ...

The Office365 driver doesn't expose the things you can do in [set|get|
remove]-mailbox or [set|get|remove]-contact or [set|get|remove]-
mailcontact, or a bunch of other stuff you can do in PowerShell. It
exposes only what you can do in the msol-user commandlets.

It makes sense, because I'm also working on some things needing access to
these various other commandlets. For now, I'm dumping out what I need via
a DelimText driver, and doing the dirty work in PowerShell myself with a
few scripts. That's good enough for what I need for now, but not good
enough long term.

I'm pushing for the NetIQ guys to dramatically expand the functionality
of this driver. I need access to the array of powershell commandlets to
manage this thing, way beyond what msol-user and friends supports.
Alternately, I'm going to have to convert my DelimText and scripting
hacks over to the scripting driver, which will work, but is kinda hokey.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Office 365 Driver: Attribute Re-Mapping for Email Address

David Gersic wrote:

> I'm pushing for the NetIQ guys to dramatically expand the functionality
> of this driver. I need access to the array of powershell commandlets to
> manage this thing, way beyond what msol-user and friends supports.
> Alternately, I'm going to have to convert my DelimText and scripting
> hacks over to the scripting driver, which will work, but is kinda hokey.


I've just finished writing a generic scripting driver solution for exactly this type of thing.

It can in theory execute any cmdlet from the Exchange Online or the MSOL modules. Has only really been tested with the various Contact/MailContact cmdlets.

The scripts can accept the following commands: "query, add, modify, delete" and return "status, instance, add-association" as appropriate.

No polling suport (so no publisher channel).
Heartbeat is still a work in progress due to bug 905134 (testing a fix for this)

Each attribute in a command is mapped to a corresponding property on the relevant cmdlet, attributes that cannot be mapped are omitted. This is performed by the powershell scripts before executing the command.

In the case where more than 1 cmdlet is required to update the object in O365, the driver can be configured to clone the event simply via a mapping table.

So. for example to update all attributes on a Contact in O365, requires both: Set-Contact and Set-MailContact so the policy would clone the modify event and change the cloned event's object class based on the mapping table.

As is common with powershell and the scripting driver, this isn't a very fast driver. There is potential for optimization but it works fine for my needs as-is.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Office 365 Driver: Attribute Re-Mapping for Email Address

> As is common with powershell and the scripting driver, this isn't a very fast driver. There is potential for optimization but it works fine for my needs as-is.

I hear the PowerShell commands themselves are quite slow in general for
O365 functionality.

What kind of performance are you seeing?


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Office 365 Driver: Attribute Re-Mapping for Email Address

Geoffrey Carman wrote:

> > As is common with powershell and the scripting driver, this isn't a very fast driver. There is potential for optimization but it works fine for my needs as-is.

>
> I hear the PowerShell commands themselves are quite slow in general for O365 functionality.
>
> What kind of performance are you seeing?


Query: 6.5 seconds
Add: 13 seconds - (it's generally less than 6 seconds but there is an embedded query for matching that doubles the processing time)
Modify: 6.5 seconds
Delete: 3.5 seconds

However, for contacts, because the initial add for MailContact can only set half the attributes, we need to trigger a modify against Contact object after the successful add.
I just made a few tweaks and got that to run in 15 seconds (add + query for match + add assoc + trigger modify against contact object).

Might be able to shave 2 more seconds off that, but we're still looking at 10+ seconds for each add and approx 5 seconds for any subsequent modify.
All these were measured from Start Transaction to End Transaction.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Office 365 Driver: Attribute Re-Mapping for Email Address

On 11/16/2014 7:27 AM, Alex McHugh wrote:
> Geoffrey Carman wrote:
>
>>> As is common with powershell and the scripting driver, this isn't a very fast driver. There is potential for optimization but it works fine for my needs as-is.

>>
>> I hear the PowerShell commands themselves are quite slow in general for O365 functionality.
>>
>> What kind of performance are you seeing?

>
> Query: 6.5 seconds
> Add: 13 seconds - (it's generally less than 6 seconds but there is an embedded query for matching that doubles the processing time)
> Modify: 6.5 seconds
> Delete: 3.5 seconds
>
> However, for contacts, because the initial add for MailContact can only set half the attributes, we need to trigger a modify against Contact object after the successful add.
> I just made a few tweaks and got that to run in 15 seconds (add + query for match + add assoc + trigger modify against contact object).
>
> Might be able to shave 2 more seconds off that, but we're still looking at 10+ seconds for each add and approx 5 seconds for any subsequent modify.
> All these were measured from Start Transaction to End Transaction.


With your scripting or with out of box O365?

That is really painfully slow. My point though was, it was the
PowerShell to O365 issue that is slow, not the engine, right?

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Office 365 Driver: Attribute Re-Mapping for Email Address

Geoffrey Carman wrote:

> With your scripting or with out of box O365?
>
> That is really painfully slow.


That is normal performance for the powershell scripting driver (with trace level 0 on both sides)
I've done, I think 8 distinct scripting driver/powershell projects now.
I learnt early on to set the customer's expectations regarding performance (especially during initial sync).

We're always talking seconds for each command.

The process is:

0. Script service loads a powershell session and keeps in memory (for performance)
1. RL/shim recieves the operation from engine, parses it. Converts the XML to name-value pairs and writes this to a temp file on the filesystem.
2. RL uses the script client to tell the script serice to run the powershell script with the path the temp file as a parameter
3. The pinned powershell session executes the script, which in turn parses this temp file, and does it's magic
a. if necessary the script calls out to O365 via remote session.
b. Script writes a second temp file (with output from command) and terminates (hopefully without error)
4. RL/shim parses the second temp file, generates a XML document and if necessary sends it back to the engine.


> My point though was, it was the PowerShell to O365 issue that is slow, not the engine, right?


The issue is within the powershell scripts, though not just with the O365 part.


Times in seconds.

For Delete:

Total Time: 03.075
Script Time: 03.048

For Modify:

Total Time: 03.066
Script Time: 03.051

For Add:

Total Time: 06.138
Script Time (Query): 03.053
Script Time (Add): 03.058


So mostly script/remote loader bound.

The other transactions vary more considerably (there appears to be some improvement after a few have been processed).

I have got an add down to about 9.5 seconds (including the match + modify-contact). For initial provisioning to an empty O365 tenant, worth temporarily disabling the matching code. Would save 33% time-wise.

Just for fun, I took the delete script and disabled the actual lines that cause it to connect to Exchange Online/O365 (so it didn't actually delete).
Still took 2 seconds just for the RL side to complete.


I don't think I've seen a non-trivial example where a script runs in less than 1 second.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Office 365 Driver: Attribute Re-Mapping for Email Address

On Sun, 16 Nov 2014 01:28:33 +0000, Geoffrey Carman wrote:

>> As is common with powershell and the scripting driver, this isn't a
>> very fast driver. There is potential for optimization but it works fine
>> for my needs as-is.

>
> I hear the PowerShell commands themselves are quite slow in general for
> O365 functionality.
>
> What kind of performance are you seeing?


Performance with O365 ranges from good to abysmal, with no rhyme or
reason why. After enabling the Exchange license for an account, for
example, the mailbox create and subsequent attribute updates can happen
anywhere from immediately to half an hour later, which is exciting if
you're waiting for the attributes to show up so that you can further
modify them in another PowerShell script.

I thought polling loops went out with button shoes. I was wrong...


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Office 365 Driver: Attribute Re-Mapping for Email Address

David Gersic wrote:

> Performance with O365 ranges from good to abysmal, with no rhyme or
> reason why. After enabling the Exchange license for an account, for
> example, the mailbox create and subsequent attribute updates can happen
> anywhere from immediately to half an hour later, which is exciting if
> you're waiting for the attributes to show up so that you can further
> modify them in another PowerShell script.


OK, that is pretty bad. I've been working with MailContacts almost exclusively in my testing. They are far less complex objects from an O365 perspective (and don't require a license)
Have not had much more time to try and squeeze better peformance out of my scripts, I'm sure I could shave an additional second or so if I used some more caching.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Office 365 Driver: Attribute Re-Mapping for Email Address

On Tue, 18 Nov 2014 18:11:35 +0000, Alex McHugh wrote:

> David Gersic wrote:
>
>> Performance with O365 ranges from good to abysmal, with no rhyme or
>> reason why. After enabling the Exchange license for an account, for
>> example, the mailbox create and subsequent attribute updates can happen
>> anywhere from immediately to half an hour later, which is exciting if
>> you're waiting for the attributes to show up so that you can further
>> modify them in another PowerShell script.

>
> OK, that is pretty bad. I've been working with MailContacts almost
> exclusively in my testing. They are far less complex objects from an
> O365 perspective (and don't require a license)


Yep. As part of our migration, we're using MailContacts initially in O365/
Exchange, then once the real Exchange mailbox is created, moving the
"Legacy Exchange DN" attribute from the MailContact to the mailbox. This
requires a no-sh*t polling loop waiting for the mailbox to exist, so that
it can be updated. Normally the loop runs only a few seconds, but I've
seen upwards of 30 minutes on some of them.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Office 365 Driver: Attribute Re-Mapping for Email Address

On 11/18/2014 2:00 PM, David Gersic wrote:
> On Tue, 18 Nov 2014 18:11:35 +0000, Alex McHugh wrote:
>
>> David Gersic wrote:
>>
>>> Performance with O365 ranges from good to abysmal, with no rhyme or
>>> reason why. After enabling the Exchange license for an account, for
>>> example, the mailbox create and subsequent attribute updates can happen
>>> anywhere from immediately to half an hour later, which is exciting if
>>> you're waiting for the attributes to show up so that you can further
>>> modify them in another PowerShell script.

>>
>> OK, that is pretty bad. I've been working with MailContacts almost
>> exclusively in my testing. They are far less complex objects from an
>> O365 perspective (and don't require a license)

>
> Yep. As part of our migration, we're using MailContacts initially in O365/
> Exchange, then once the real Exchange mailbox is created, moving the
> "Legacy Exchange DN" attribute from the MailContact to the mailbox. This
> requires a no-sh*t polling loop waiting for the mailbox to exist, so that
> it can be updated. Normally the loop runs only a few seconds, but I've
> seen upwards of 30 minutes on some of them.



O365 is an SEP field.
http://hitchhikers.wikia.com/wiki/Somebody_Else%27s_Problem_field


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.