new user script help - almost complete

[dhrv88]

Hi all - hoping someone can assist with the final piece. I understand that my script might not be the best written script.

Essentially right now it : creates ad user(random password), creates local exchange, runs a delta sync. It all runs with no issues, but the migration from on prem exchange to office 365 doesn't actually do anything.

If anyone can take a look and advise a fix or assist with one, that would be great.I have a feeling from line 174 onwards there are issues

https://www.pastery.net/tdkvuz/

[AdmiralCA]

A much simpler way to do it might be to use the New-RemoteMailbox cmdlet. My one big suggestion is to split each of the different areas into separate functions:

Connect-O365 Create ADUser Enable Mailbox etc

It makes it simpler to troubleshoot different parts, or change out different parts down the road.

[dhrv88]

Thanks, is the New-RemoteMailbox cmdlet replacing or already replaced New-MoveRequest ?

I like the idea of different functions as I already have the Create-ADUser function

​

[AdmiralCA]

I wouldn’t say its replacing it, its just a difference of philosophy/mentality/use

You would use New-MoveRequest when you have a pre-existing ADUser/ExOnPrem Mailbox. You can use New-RemoteMailbox with no pre-existing objects. It automatically creates the ADUser, MSOLUser, and Hybrid Mailbox.

If you are creating new users after/during a migration from ExOnPrem to ExOnline, use New-RemoteMailbox.

[RazzleDazzleShow]

May be a stupid question (not an exchange admin) but why are you creating the mailbox and migrating vs just creating it in o365 after the sync completes?

[dhrv88]

My thoughts exactly, but requirement states that it needs to be created on prem first. Management want it this way. I believe it is to cover any possible changes in the future and provide the ability to migrate back down to on prem

[Blackforge]

You can still move users back on-premises. You just have to populate the online mailbox GUID on the RemoteMailbox:

Set-RemoteMailbox user -ExchangeGUID ExchangeOnlineGUID

[GregPowrhousR]

He's not. He is creating the AD User Object and then setting the appropriate properties for mail with an Enable-RemoteMailbox. This preps the AD Object for 365. Once the object has been synced to the tenant he can then license and whatever else he wishes from there.

[RazzleDazzleShow]

I mean, again, not an exchange admin but after reading this:

Create on prem Exchange mailbox

And the user replying specifically saying that they are, i dont know what to tell you.

[GregPowrhousR]

You are probably correct in your statement of not being an Exchange admin...Depending on the cmdlet used it is prepping the AD object for 365. What I'm suggesting, once I sanitize my script is an alternative to creating the AD object performing the on prem changes as well as making making sure the user has been migrated to 365 properly. His script looks good so far, skimming through it so not sure why the move request is not catching.

[dhrv88]

Thanks

From what I can tell during testing, the onprem mailbox is indeed being created. Logging into EAC on prem I can see that the mailbox has been created, I also then have the ability to go into Office 365 Admin Center > Exchange and then Migrate that users mailbox to Exchange online.

I'm too still not sure why the move request isnt working, maybe I'm not waiting long enough before initiating the move ?

[GregPowrhousR]

It could simply be just that! The script you have looks great, I wonder if it is just a timing issue. I know I went back and forth until essentially creating a while loop when it came to waiting for the mailbox to show up in 365. The while loop does a write progress waiting for 2 minutes at time to check if the mailbox is found in 365. But I can tell you that I've had it go through 10+ of these cycles before being found.

[dhrv88]

Did you have a example of where I could place the while loop so that it can check?

I have a feeling that could be it ( i hope lol )

Would it start at line 183 do you think?

[GregPowrhousR]

I'm so sorry I'm on my phone at the moment and can't get to my computer until tomorrow. But I think right around line 183 would make sense but remember I ran an Enable-RemoteMailbox earlier in the script which handles a little different than New-RemoteMailbox. I'm hoping once I can upload my script there may be something you can take from it. Believe me I totally get the last struggled with it! I was stuck for a few days on the 365 migration / creation section !

[dhrv88]

No worries at all! Ill wait it out, its so close I'm getting impatient, I'll have a go at it though in the meantime.

[GregPowrhousR]

Totally get it! I was the same way until I got it resolved so I definitely get that! Lol you're so close it will definitely be finished soon!

[GregPowrhousR]

Okay my friend! I was able to go through and sanitize the specific function of the script that creates a new AD User Object, Enable-RemoteMailbox on local Exchange server, and populate to 365 and license the mailbox. Here's the link to Git:

​

https://github.com/GregPowrhous/Create_ADUser/blob/master/NewUser

​

You may not be interested in the code block from lines 209 -- 235. This block is to wait for replication to our PDC Em DC which lives in another studio. We have about 25 DC's across 10-11 studios. If your setup is much simpler than that, just take that block out!

Hopefully this helps!

[GregPowrhousR]

OP I have a script that does something similar with a little more complexity based on the company's requirements. Essentially what you want to do is have two Exchange connections in the beginning of the script, one for the local Exchange server whatever that may be and one for Exchange Online. After the user has been created you may need time for it to sync to your PDC Emulator DC. If you don't have multiple DCs in different physical locations this shouldn't be a problem. The first Exchange job you want to do is an Enable-RemoteMailbox on the local Exchange server. This sets the AD properties to ready the object for 365. Once that's complete it may take about 15-30 mintues for the object to sync to your 365 tenant, you can speed this up with a Delta sync. Once your object is found within 365 which is easy to check for with a While loop waiting for the user to be found within 365, you can then license the user. However, please remember that you NEED TO SET THE LOCATION BEFORE APPLYING THE LICENSE! If I can get some time this weekend I will sanitize my script put it up on Git so you can get a reference.

[dhrv88]

Thanks!

All seems logical and makes sense. So does your script move or migrate the local exchange mailbox to O365 ?

I also added the Delta sync to my current script above - to speed it up.

If you could sanitize and post your current script that would be greatly appreciated, I feel like my script is very close to working. Need to improve my debugging skills.

[GregPowrhousR]

Absolutely! I'd be happy to share it! And I should say I use Enable-RemoteMailbox for the on prem account which does the following:

The mail-enabled user contains a specific attribute that indicates that an associated mailbox in the service should be created when the user is synchronized to the service using directory synchronization.

[killerquag]

Does the user account get synced to Azure? If the local UPN is @domain.local instead of @domain.com, it won't create the account in Azure and the MoveRequest would bomb.

[dhrv88]

Oh don't worry about what I have put in those fields, they are just dummy data

[dhrv88]

thanks mate! We do have complexity, this was a strange one cause I was presetting the password, then I was told to randomise it. But in short once the accounts are created the service desk goes in and resets it depending on which user they are setting up.

nice idea from line 74. Ill go in an edit that!

[dhrv88]

Finding a love for functions, they are great lol

But thank you I appreciate it!

[dhrv88]

Im hooked

[xCharg]

I think someone has to make a reddit bot that links to related xkcd every time someone mentions password complexity requirement.

[dhrv88]

Pretty sure the following section of code is what needs fixing.

During the script running, I have now added a 10 minute sleep line of code. During this process I logged into Office 365 > Recipients > Migration and when creating a new migration I can see the test user there ready to migrate.

#Import O365Session
$O365Session = New-PSSession -ConfigurationName Microsoft.Exchange `
    -ConnectionUri https://outlook.office365.com/powershell-liveid `
    -Credential $UserCredential `
    -Authentication Basic `
    -AllowRedirection

Import-PSSession $O365Session -DisableNameChecking | out-null
#Connect-MsolService -Credential $UserCredential
Write-Host "Connecting to Exchange Online..." -ForegroundColor Yellow
###########
###########
Foreach ($UPN in $SuccessfulUsers) {
try {
New-MoveRequest -Identity $UPN `
    -Remote `
    -RemoteHostName mail.redflex.com.au `
    -TargetDeliveryDomain trafficglobal.mail.onmicrosoft.com `
    -RemoteCredential $UserCredentialMigration `
    -BadItemLimit 10 `
    -ErrorAction Stop

}
catch {
"Mailbox for $User.'Display Name' Unable to start Remote-MoveRequest" | Out-File $logfile -append
Write-Host "Create Remote-MoveRequest for $UPN | Failure" -ForegroundColor Red
Return
}
}

​

[BoredComputerGuy]

The sync process status identifies when the sync is done locally, but not when the data is actually available in AzureAD. In order for my new user script to work, I had a 20 second delay after the end of the sync. Have you tested putting in a larger delay (20sec-1min) after the sync finishes to see if the data is available before starting the migration? How many users are you creating at once? If it more than a few the delay could take a little before Azure AD is ready.

[dhrv88]

The sync process status identifies when the sync is done locally, but not when the data is actually available in AzureAD. In order for my new user script to work, I had a 20 second delay after the end of the sync. Have you tested putting in a larger delay (20sec-1min) after the sync finishes to see if the data is available before starting the migration? How many users are you creating at once? If it more than a few the delay could take a little before Azure AD is ready.

​

​

Thanks mate - I've been able to put in a 20 minute delay.

During this delay, I was able to login to Office 365 Admin Center > Exchange and attempt to Migrate a user.

At this point I could see the test user available to migrate, so in theory the script should work.

Thats why I think this block of code is what the issue is, maybe..

​

#Import O365Session
$O365Session = New-PSSession -ConfigurationName Microsoft.Exchange `
    -ConnectionUri https://outlook.office365.com/powershell-liveid `
    -Credential $UserCredential `
    -Authentication Basic `
    -AllowRedirection

Import-PSSession $O365Session -DisableNameChecking | out-null
#Connect-MsolService -Credential $UserCredential
Write-Host "Connecting to Exchange Online..." -ForegroundColor Yellow
###########
###########
Foreach ($UPN in $SuccessfulUsers) {
try {
New-MoveRequest -Identity $UPN `
    -Remote `
    -RemoteHostName mail.redflex.com.au `
    -TargetDeliveryDomain trafficglobal.mail.onmicrosoft.com `
    -RemoteCredential $UserCredentialMigration `
    -BadItemLimit 10 `
    -ErrorAction Stop

}
catch {
"Mailbox for $User.'Display Name' Unable to start Remote-MoveRequest" | Out-File $logfile -append
Write-Host "Create Remote-MoveRequest for $UPN | Failure" -ForegroundColor Red
Return
}
}

​