Convert Synced User into In-Cloud only User

Convert Synced User into In-Cloud only User

In this example I have local Active Directory with AAD Connect installed one of the Azure Region, which sync users and password hash to Office 365. I have now decided to migrate the authentication from local Active Directory to Office 365 and decommission on-premises Active Directory.

Azure Active Directory Connect Diagram

In order to transition from on-premises “Synced Identity” to “In Cloud Identity”, we will need to complete the following process.

Sign into the AAD Connect Server and Sync the Delta

The following command performs a sync of all AD Objects before attempting to convert into Cloud Only.

1
Start-ADSyncSyncCycle Delta

Turn off AAD Connect Sync

The following command turns off Azure Active Directory Connector while we perform all the following tasks. In this post I have outlined all steps which can be taken to convert AD Users account into Cloud Only.

1
Set-MsolDirSyncEnabled -EnableDirSync $false

Convert Single User to Cloud Only

The following command converts a single user into a Cloud Only account

1
Get-MsolUser -UserPrincipalName thewatchernode@blogabout.cloud | Set-MsolUser -ImmutableId $null

Remove Immutable ID of all users

The following command removes the Immutable ID for all users

1
Get-MsolUser | Set-MsolUser -ImmutableId $null

Remove Immutable ID for Bulk users

The following scripts allows you to modify users at bulk

$Filepath = $env:userprofile\desktop\file.csv
$csv = Import-Csv -Path $filepath
$immutableID=$null

Foreach($user in $csv)
{
Set-MsolUser -UserPrincipalName $user.UserPrincipalName -ImmutableID $immutableID
}

Turn on Azure Active Directory Connect Sync

Once you have completed all the required conversions of AD accounts to Cloud. Head back to your local Active Directory, move user(s) to an OU that isn’t synchronized using AADC.

This helps you as an IT Pro understand who has been converted at a quick glance now not worry about using PowerShell to discovery who is or isn’t.

The following command turns on Azure Active Directory Connector now that we have converted the users accounts to Cloud Only

1
Set-MsolDirSyncEnabled -EnableDirSync $true

Enable Force Sync if the Sync didn’t work

1
 Start-ADSyncSyncCycle -PolicyType Initial

If you are using an ADFS Server there is an additional step providing you have moved all your users to the Cloud. You will need to change the Federated Domain to Standard Domain


1
Convert-MsolDomainToStandard -DomainName blogabout.cloud -WhatIf<br>Convert-MsolDomainToStandard -DomainName
1
blogabout.cloud -Confirm

All that is left now is to log in as one of the converted users to prove Single Sign-On is working and logon as a Global Admin into Office 365 to check the sync status of the users has a pretty cloud for “In-Cloud”

Regards
The Author – Blogabout.Cloud

Directory Based Edge Blocking in Exchange Online or (DBEB for short)

Directory Based Edge Blocking in Exchange Online or (DBEB for short)

What is DBEB? It is a solution that allows an organization to reject message for invalid recipient at the service network perimeter. DBEB enables your Office 365 Global Administrator to add mailed-enabled recipients to Office 365 and block all messages sent to email address that aren’t present in Office 365.

Valid messages are then subject to the rest of the service filtering layers which are;

Antimalware
Antispam
Mail Flow Rules (otherwise knows as Transport Rules)

Invalid messages are blocked before filtering even occurs, and a non-delivery report (also known as an NDR or bounce message) is returned to the sender. The NDR looks like this:

1
550 5.4.1 [&lt;InvalidAlias>@\&lt;Domain>]: Recipient address rejected: Access denied

Important Note

In hybrid environments, in order for DBEB to work, email for the domain must be routed to Office 365 first (the MX record for the domain must point to Office 365).

Configuring DBEB

First of all, you need to verify that your accepted domain EXO is an Internal Relay, this is done by going to Exchange Admin Console –> Mail Flow –> Accepted domains.

If, your domain type is Authoritative you will need to click the edit button and set to internal relay

Adding your users to Office 365

In the EAC, go back to Mail flow > Accepted domains.

Select the domain and click Edit.
Set the domain type to Authoritative.
Choose Save to save your changes, and confirm that you want to enable DBEB.

  • Until all of your valid recipients have been added to Exchange Online and replicated through the system, you should leave the accepted domain configured as Internal relay. Once the domain type has been changed to Authoritative, DBEB is designed to allow any SMTP address that has been added to the service (except for mail-enabled public folders). There might be infrequent instances where recipient addresses that do not exist in your Office 365 organization are allowed to relay through the service.
  • For more information about DBEB and mail-enabled public folders, see Office 365 Directory Based Edge Blocking support for on-premises Mail Enabled Public Folders.

Regards.
The Author – Blogabout.Cloud

Get Disabled Users who have an Exchange Mailbox with PowerShell

Get Disabled Users who have an Exchange Mailbox with PowerShell

If there’s one thing most IT department are not great at its removing Exchange Mailboxes for Disabled Users. So here’s a quick Powershell win to determine who within your Exchange organisation has a mailbox and a disabled AD account.

On-Premises Users


1
2
3
4
5
6
7
8
9
$Mailboxes = Get-Mailbox | where {$_.RecipientTypeDetails -eq 'UserMailbox'}
$Disabled = @()

Foreach ($Mailbox in $Mailboxes) {
    if((Get-ADUser -Identity $Mailbox.SamAccountName).Enabled -eq $False){
        $Disabled += Get-MailboxStatistics $Mailbox.SamAccountName | Select -Property DisplayName,TotalItemSize
    }    
}
$Disabled | Export-Csv -Path $env:userprofile\desktop\DisabledADUserwithMailbox.csv -NoTypeInformation

Cloud Users


1
2
3
4
5
6
7
8
9
10
11
Connect-MsolService
 
  $Mailboxes = Get-Mailbox | Where-Object {$_.RecipientTypeDetails -eq 'UserMailbox'}
  $Disabled = @()

  Foreach ($Mailbox in $Mailboxes) {
    if((Get-msolUser -userprincipalname $Mailbox.userprincipalname).Enabled -eq $False){
        $Disabled += Get-MailboxStatistics $Mailbox.userprincipalname | Select-Object -Property DisplayName,TotalItemSize
    }    
  }
  $Disabled | Export-Csv -Path $env:userprofile\desktop\DisabledAzureADUserwithMailbox.csv -NoTypeInformation

Regards

The Author – Blogabout.Cloud

Going back to CSVDE School -Parameters, Switches you name it… We do Old Skool..

Going back to CSVDE School -Parameters, Switches you name it… We do Old Skool..

Before the joys of Export-CSV there used to be another way of dumping Active Directory data to CSV using again native tooling. In a recent project I have had to rediscover the old ways and go back to school to learn the required switches, which I am now going to share with you all.

Image result for great scott gif

SwitchDescription
-aUserDistinguishedName Password.  If you must use these switches, then treat  -a and -b as a pair.  A likely scenario is that you are logged on as non-administrator and wish to run CSVDE against your Active Directory.  As a non-administrator, you would get an error unless you employ these switches to connect with the correct credentials
-bUserDistinguishedName Password.  If you must use these switches, then treat  -a and -b as a pair.  A likely scenario is that you are logged on as non-administrator and wish to run CSVDE against your Active Directory.  As a non-administrator, you would get an error unless you employ these switches to connect with the correct credentials
-cString1 String2.  This switch replaces all olddomain names in String1 with newdomain names String2.  Could be used to change all dc=oldom distinguished name in the export domain (String1) with dc=newdom of the import domain (String2). 
-dThis is useful filter switch for when you want to export from just one OU.  Use the -d switch to set the root directory for the export.  For example, if you are only interested in an OU called Newport type, CSVDE -f export.csv -d “OU=mycompany,DC=domain,DC=com”.  Note, there are no spaces between domain,DC=com.
-ffilename is a mandatory switch for both import and export.  Simply specify the .csv file for transfer data.  It makes life easier if this file is in the same directory as you issue the CSVDE command.  Here is an export example CSVDE -f export.csv
-gOmits paged searches.   I have never bothered with this switch.
-iSwitches CSVDE to import mode.  For example, CSVDE -i -f export.csv.  Remember that the default mode is export, in which case it’s just plain CSVDE -f FileName.csv 
-jPath Sets the log file directory.  The point of a log file is that it’s permanent where as the -v verbose mode is ephemeral.  -j creates one or two log files.  It always creates a file called csv.log, additionally it creates csv.err if it encounters any errors.
-jTrap: As far as I can see without the -j switch, CSVDE will not create a log file at all.  I mention this as other documentation suggests that you are just setting the path, in my opinion, with -j you are creating the file as well as setting its path.
-kUseful for ignoring simple errors: “Object already exists,” “Constraint violation,” and “Attribute or value already exists.”  I almost always use this switch as part of the CSVDE import command
-lLDAP Attributes.   On the one hand, I think of L for list, on the other hand I think of -l as a column-wise filter.  What this switch does is export only the LDAP properties that you are interested in and ignores the rest of the attributes.  Example CSVDE -f export.csv  -l “DN, objectclass, objectcategory, givenName, sn”.  Note the position of speech marks and commas.
-mAnother column-wise filter.  Omits Active Directory properties such as the ObjectGUID, objectSID, pwdLastSet and samAccountType attributes.

I hope these switches help you, like they have helped me and credit to all the previous bloggers which enabled me to get this list together.

Regards

The Author – Blogabout.Cloud

Is Get-ADUser a bit slow in getting required result? Hello ADSISearcher using PowerShell.

Is Get-ADUser a bit slow in getting required result? Hello ADSISearcher using PowerShell.

Sometimes Get-ADUser just isn’t enough if you are working thousands upon thousands of AD Objects. In a recent scenario, while resolving an Active Directory Health issue. I needed the ability to be able to compare AD Objects from 2 Active Directory Domains from within a resource forest.


What is ADSISearcher?

ADSISearcher is a command line driven LDAP Lookup procedure has the ability to query Active Directory. As ADSISearcher looks up Active Directory it enables a faster discovery of the required AD Objects.

My scenario

I need to ensure CustomAttribute10 in Child1.domain.com matches CustomAttribute10 in Child2.domain.com, yes I could use Get-ADUser | export-csv but this has proved to take to long and needed a faster solution.

ADSISearcher has proved to reduce the time required to execute this script and dumping out to a transcript file with “,” separating the text allows the information to be imported to excel if required.

The script

 Clear-Host
Write-Host "You are currently running Version 1.0" -BackgroundColor DarkGray
[string] $Menu = @'
┌─────────────────────────────────────────────────────────────┐
ADSISearcher for CustomAttribute10
Created by @thewatchernode
└─────────────────────────────────────────────────────────────┘
'@
Menu
$Menu
Transcript
Start-Transcript -Path "$env:userprofile\Desktop\Child1vsChild2.txt"
Start Time
$start = [datetime]::Now
region Client Array
$Child1LDAPFilter = '(objectclass=user)'
$PageSize = 1000
$Child1DN = 'DC=child1,DC=domain,DC=com'
$Child1SB = 'DC=child1,DC=domain,DC=com'
$Child1Searcher = [ADSISearcher]('{0}' -f $child1LDAPFilter)
$Child1Searcher.SearchRoot = [ADSI]('GC://{0}' -f $Child1SB)
$Child1Searcher.SearchRoot = [ADSI]('GC://{0}' -f $child1DN)
$Child1Searcher.PageSize = $PageSize
$Child1Objects = $Child1Searcher.FindAll()
endregion
region Collab Array
$Child2SB = 'DC=child2,DC=domain,DC=com'
$Child2DN = 'DC=child2,DC=domain,DC=com'
endregion
region Client vs Collab
Foreach($Object in $child1Objects){
$childca10 = $Object.Properties.'customattribute10'
$Child2LDAPFilter = "(objectclass=user,customattribute10=$childca10)"
$child2Searcher1 = [ADSISearcher]("{0}" -f $child2LDAPFilter)
$child2Searcher1.SearchRoot = [ADSI]("GC://{0}" -f $Child2SB)
$child2Searcher1.SearchRoot = [ADSI]("GC://{0}" -f $Child2DN)
$child2Searcher1.PageSize = $PageSize
#$AllObjects1 = $collabSearcher1.FindAll()
$nullvalue = $object.Properties.'customattribute10'
if ($nullvalue -eq $null)
{
Write-Host 'INFO, Null Value Found in Child Domain 1,' $Object.Properties.samaccountname -BackgroundColor Red
}
else
{
try
{
($Object.Properties.'customattribute10' -eq $child2searcher1.Properties.'customattribute10')
Write-Host 'Skipping, Attribute match found in Child domain 2 using Child domain 1,' $Object.Properties.samaccountname -ForegroundColor Green
}
catch
{
Write-Host 'INFO, No Attribute match found in Child domain 2 using Child domain 1,' $Object.Properties.samaccountname -BackgroundColor Red
}
}
}
endregion
Stop Transcript
Stop-Transcript
End Time
$end = [datetime]::Now
$resultTime = $end - $start
Write-Host ('Execution : {0}Days:{1}Hr:{2}Min:{3}Sec' -f $resultTime.Days, $resultTime.Hours, $resultTime.Minutes, $resultTime.Seconds)

Download

Get-ADSISearcher (40 downloads)

Regards

The Author – Blogabout.Cloud