What also doesn't synchronize is mail-enabled public folders that are members of distribution groups.  DirSync will synchronize the on-premises group object, but the public folder is not included as a group member.  Therefore, the on-premise public folder does not receive the message when migrated users send email to the distribution group.  The solution is to create a contact which represents the mail-enabled public folder and make it a member of the distribution group so that DirSync can synchronize it.  This can be automated using PowerShell.

Let’s start by setting a few variables for the data files, the SMTP domain, and the target OU where contacts will be created:

$MailFolders = ".\MailFolders.csv"

$MailFolderMembers = ".\MailFolderMembers.csv"

"FolderName,FolderAlias,FolderEmail,GroupName,GroupAlias,GroupEmail" | Out-File $MailFolderMembers

$SmtpDomain = "@contoso.com"

$TargetOu = "OU=PFContacts,DC=contoso,DC=com"

In addition to Exchange Management Shell, the script will require the Active Directory module:

Import-Module ActiveDirectory

If ((Get-Module -Name ActiveDirectory) -eq $null) { Break }

The script will first enumerate all the mail-enabled public folders and export them to a CSV dataset:

Get-MailPublicFolder -ResultSize Unlimited | Select Alias, DisplayName, PrimarySmtpAddress | Export-Csv $MailFolders –NoTypeInformation

Next we will search every distribution group to check if its membership includes a mail-enabled public folder and export the results to another CSV dataset:

$DistributionGroups = Get-DistributionGroup -ResultSize Unlimited

ForEach ($Group in $DistributionGroups) {

$GroupName = $Group.Name

$GroupAlias = $Group.Alias

$GroupEmail = $Group.PrimarySmtpAddress

Get-DistributionGroupMember $Group -ResultSize Unlimited | Where { $_.RecipientType -eq "PublicFolder" } | ForEach {

$MemberName = $_.Name

$MemberAlias = $_.Alias

$MemberEmail = $_.PrimarySmtpAddress

"$MemberName,$MemberAlias,$MemberEmail,$GroupName,$GroupAlias,$GroupEmail" | Out-File $MailFolderMembers -Append } }

Then we need to create a hidden contact which represents the mail-enabled public folder.  However, the mail attributes we need to use for the contact (alias, email address, etc.) are already assigned to the public folder.  Therefore, we need to create the contact using temporary values and forcibly manipulate the AD attributes after creation:

Import-Csv $MailFolders | ForEach {

$ContactName = $_.Alias + "-PFContact"

$ContactAlias = $_.Alias + "-PFContact"

$ContactSmtp = $_.Alias + "-PFContact" + $SmtpDomain

New-MailContact -Name $ContactName -Alias $ContactAlias -ExternalEmailAddress $ContactSmtp -PrimarySmtpAddress $ContactSmtp -OrganizationalUnit $TargetOu

Set-MailContact $ContactAlias -HiddenFromAddressListsEnabled $true

$Contact = Get-ADObject -Filter { MailNickname -eq $ContactAlias }

Set-ADObject $Contact -Replace @{TargetAddress=$_.PrimarySmtpAddress}

Set-ADObject $Contact -Replace @{info=$_.DisplayName} }

And finally, we replace the public folder object found in each distribution group with the corresponding contact.  Exchange cmdlets don't seem to work for adding/removing public folders, so we'll use AD cmdlets instead:

Import-Csv $MailFolderMembers | ForEach {

$GroupEmail = $_.GroupEmail

$FolderEmail = $_.FolderEmail

$ContactAlias = $_.FolderAlias + "-PFContact"

$GroupDN = "LDAP://" + (Get-ADObject -LDAPFilter "(mail=$GroupEmail)").DistinguishedName

$FolderDN = "LDAP://" + (Get-ADObject -LDAPFilter "(mail=$FolderEmail)").DistinguishedName

$ContactDN = "LDAP://" + (Get-ADObject -LDAPFilter "(mailNickname=$ContactAlias)").DistinguishedName

$Group = [ADSI]$GroupDN

$Folder = [ADSI]$FolderDN

$Contact = [ADSI]$ContactDN

$Group.Add($Contact.ADsPath)

$Group.Remove($Folder.ADsPath) }

After a couple runs, DirSync will synchronize the new contacts and update the distribution group membership in O365.  As always, the script should be tested thoroughly before running against a production environment.  Each task can also be split into separate scripts so that the process can be run against a smaller dataset.  RjZ

PFtoDL.zip

Customer initially purchases E1 licenses and begins to provision and migrate accounts using the included service options (i.e. Exchange, SharePoint, and/or Lync).  Customer then realizes they require an expanded feature set and decides to purchases E3 licenses to replace the E1.  However, by this time many users already have a live Exchange mailbox under E1.  To complicate matters further, some users have now been enabled for SharePoint and/or Lync using the new E3 license while Exchange is still enabled under the original E1.  (Yes, this is possible as long as the same service is not enabled in both SKUs.)  Wow, what a mess!  So, how do we “flip” all the E1 licenses to E3 without data loss?  I’m glad you asked :-)

First, a couple key considerations:  (1) un-assigning an Exchange license for users which have already been enabled can result in the re-provisioning of an empty mailbox; (2) at no point can the same service be enabled under two different SKUs; (3) if Office Web Apps is to enabled under E3 then SharePoint must also be assigned under E3.  Scared yet?  Here we go…

We will definitely need some logging for this:

$LogFile = "c:\o365\SwitchLicense.log"; Get-Date | Out-File $LogFile

We already know that if the user does not have a mailbox under E1, we will not be enabling the Exchange option under E3.  So, let’s define that license option:

$NoExchange = New-MsolLicenseOptions -AccountSkuId "tenant:ENTERPRISEPACK" -DisabledPlans "EXCHANGE_S_ENTERPRISE"

Next, we’ll create a data set to run against.  As always, I prefer to use a CSV import when making bulk changes.  But, the task could be run against all accounts.  In either case, keep in mind that some users may have both E1 and E3 assigned.  So, we must query for each.  If the user is not licensed at all, then we’ll make note of that in the log file and move on:

Import-Csv "c:\o365\ImportFile.csv" | ForEach {

#Get-MsolUser -All | ForEach {

$Upn = $_.UserPrincipalName; $Licensed = $_.IsLicensed

$UserLicense0 = (Get-MsolUser -User $Upn).Licenses[0]

$UserLicense1 = (Get-MsolUser -User $Upn).Licenses[1]

If ($Licensed -eq $False) { "SKIP: No license currently assigned [$Upn]" | Out-File $LogFile -Append }

If the user is currently licensed for only E3, then there is nothing to “flip”.  We’ll make note of that in the log and continue:

If ($UserLicense0.AccountSkuId -eq "tenant:ENTERPRISEPACK" -and $UserLicense1 -eq $null)

{ "SKIP: Only E3 license currently assigned [$Upn]" | Out-File $LogFile -Append }

If the user is only licensed for E1, then we can easily flip to E3.  However, we don’t necessarily want to enable options under E3 that were not enabled under E1.  For now, let’s assume all options under E1 are disabled.  We will query the assigned E1 license to determine which options are actually enabled and write the result to the log file:

If ($UserLicense0.AccountSkuId -eq "tenant:STANDARDPACK" -and $UserLicense1 -eq $null) {

$Lync = "Disabled"; SharePoint = "Disabled"; $Exchange = "Disabled"

(Get-MsolUser -User $Upn).Licenses[0].ServiceStatus | ForEach {

If ($_.ServicePlan.ServiceName -eq "MCOSTANDARD" -and $_.ProvisioningStatus -ne "Disabled") { $Lync = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "SHAREPOINTSTANDARD" -and $_.ProvisioningStatus -ne "Disabled") { $SharePoint = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "EXCHANGE_S_STANDARD" -and $_.ProvisioningStatus -ne "Disabled") { $Exchange = "Enabled" } }

"SCAN: Only E1 license currently assigned [$Upn] Lync:$Lync, SharePoint:$SharePoint, Exchange:$Exchange" | Out-File $LogFile -Append

If the E1 user does not have Exchange assigned, we can safely flip to E3 with Exchange disabled.  However, if the E1 user does have Exchange assigned, then we must transition to E3 by removing the old license and assigning the new license in a single command.  In both cases, we will write the results to the log file:

If ($Exchange -eq "Disabled") { Set-MsolUserLicense -User $Upn -RemoveLicenses "tenant:STANDARDPACK" -AddLicenses "tenant:ENTERPRISEPACK" -LicenseOptions $NoExchange }

Else { Set-MsolUserLicense -User $Upn -RemoveLicenses "tenant:STANDARDPACK" -AddLicenses "tenant:ENTERPRISEPACK" }

"MOVE: E1 license moved to E3 [$Upn] Office:Enabled, Lync:Enabled, SharePoint:Enabled, WebApps:Enabled, Exchange:$Exchange" | Out-File $LogFile -Append }

This is where it gets tricky.  If the user has both E1 and E3 assigned, we must determine under which license Exchange is enabled.  Once again, we’ll assume all options are disabled, query both licenses to identify which options are actually enabled, and write the results to the log file:

If ($UserLicense0.AccountSkuId -eq "tenant:ENTERPRISEPACK" -and $UserLicense1.AccountSkuId -eq "tenant:STANDARDPACK") {

$Office = "Disabled"; $Lync = "Disabled"; $WebApps = "Disabled"; $SharePoint = "Disabled"; $Exchange0 = "Disabled"

(Get-MsolUser -User $Upn).Licenses[0].ServiceStatus | ForEach {

If ($_.ServicePlan.ServiceName -eq "OFFICESUBSCRIPTION" -and $_.ProvisioningStatus -ne "Disabled") { $Office = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "MCOSTANDARD" -and $_.ProvisioningStatus -ne "Disabled") { $Lync = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "SHAREPOINTWAC" -and $_.ProvisioningStatus -ne "Disabled") { $WebApps = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "SHAREPOINTENTERPRISE" -and $_.ProvisioningStatus -ne "Disabled") { $SharePoint = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "EXCHANGE_S_ENTERPRISE" -and $_.ProvisioningStatus -ne "Disabled") { $Exchange0 = "Enabled" } }

"SCAN: E3 license currently split [$Upn] Office:$Office, Lync:$Lync, WebApps:$WebApps, SharePoint:$SharePoint, Exchange:$Exchange0" | Out-File $LogFile -Append   

$Lync = "Disabled"; $SharePoint = "Disabled"; $Exchange1 = "Disabled"

(Get-MsolUser -User $Upn).Licenses[1].ServiceStatus | ForEach {

If ($_.ServicePlan.ServiceName -eq "MCOSTANDARD" -and $_.ProvisioningStatus -ne "Disabled") { $Lync = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "SHAREPOINTSTANDARD" -and $_.ProvisioningStatus -ne "Disabled") { $SharePoint = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "EXCHANGE_S_STANDARD" -and $_.ProvisioningStatus -ne "Disabled") { $Exchange1 = "Enabled" } }

"SCAN: E1 license currently split [$Upn] Lync:$Lync, SharePoint:$SharePoint, Exchange:$Exchange1" | Out-File $LogFile –Append

We’re getting close.  If Exchange is enabled under E3 in a “split license” scenario, we can safely remove E1 and enable any previously assigned options under E3.  Remember, Exchange is already enabled under E3:

If ($Exchange0 -eq "Enabled" -and $Exchange1 -eq "Disabled") {

$Exchange = "Enabled"

Set-MsolUserLicense -User $Upn -RemoveLicenses "tenant:STANDARDPACK"

Set-MsolUserLicense -User $Upn -AddLicenses "tenant:ENTERPRISEPACK" }

However, if Exchange is enabled under E1 we must first remove E3 and then flip the entire E1 license (Exchange included) in a single command:

If ($Exchange0 -eq "Disabled" -and $Exchange1 -eq "Enabled") {

$Exchange = "Enabled"

Set-MsolUserLicense -User $Upn -RemoveLicenses "tenant:ENTERPRISEPACK"

Set-MsolUserLicense -User $Upn -RemoveLicenses "tenant:STANDARDPACK" -AddLicenses "tenant:ENTERPRISEPACK }

The last possible scenario would be that Exchange is not enabled under either license.  So, we will simply remove both licenses and reassign E3 without Exchange:

If ($Exchange0 -eq "Disabled" -and $Exchange1 -eq "Disabled") {

$Exchange = "Disabled"

Set-MsolUserLicense -User $Upn -RemoveLicenses "tenant:ENTERPRISEPACK"

Set-MsolUserLicense -User $Upn -RemoveLicenses "tenant:STANDARDPACK"

Set-MsolUserLicense -UserPrincipalName $Upn -AddLicenses "tenant:ENTERPRISEPACK" -LicenseOptions $NoExchange }

Of course, we will write the results of all this license manipulation to the log file:

"JOIN: E1 license merged into E3 [$Upn] Office:Enabled, Lync:Enabled, SharePoint:Enabled, WebApps:Enabled, Exchange:$Exchange" | Out-File $LogFile –Append } }

Problem solved!  This scenario reflects an incredibly complex scenario that I hope you won’t encounter.  But, if you find yourself facing similar circumstance, I trust some of these concepts will prove useful.  It obviously goes without saying that you must thoroughly test this solution on sample accounts or a test tenant before running it against your production environment.  RjZ

BulkMigrateLicenses.zip

Let’s consider the following scenario… you have just completed a mail migration to O365 and all accounts were successfully licensed with only the Exchange option enabled.  Team Sites are now ready and you need to assign the SharePoint and Office Web Apps service for all users.  One option would be to simply enable all the remaining services in the license:

$Options = New-MsolLicenseOptions –AccountSkuId "tenant:ENTERPRISEPACK"

Set-MsolUserLicense –UserPrincipalName [UPN] –LicenseOptions $Options

Notice the absence of –AddLicenses parameter from the Set-MsolUserLicense cmdlet.  Trying to add a license that is already assigned results in an error.  Therefore, we simply enable all the other service options contained within the license.  Another method might be to remove the currently assigned license and re-apply it using the desired service options.  However, there is risk associated with removing a license.  The existing Exchange mailbox could become orphaned and an empty one re-provisioned.  Also, any related O365 service data associated with the user account might be lost.

Now, let’s consider a similar but slightly more complicated scenario. User accounts each have an inconsistent mix of service options enabled; some have SharePoint enabled, some have Lync enabled, and not all have Exchange.  How do you assign the Office subscription (for example) to all accounts?  You can’t blindly enable all remaining options, as this would provide access to services which may not be desired.  Removing the license and re-applying it also proves difficult. The solution is to query each user accounts to determine which service options are currently active or inactive, add the service you would like to enable, and assign the results.  (NOTE: This is written for E3 license, but easily adapted for other SKUs.)

First, we'll create a data set to run against.  I typically prefer using a CSV import file when making bulk changes, but the task could also be run against all licensed accounts:

Import-Csv c:\o365\AssignOption.csv | ForEach {

#Get-MsolUser –All | Where { $_.IsLicensed –eq $true } | ForEach {

$Upn = $_.UserPrincipalName

Let’s initially assume all service options for the user are currently disabled:

$Exchange = "Disabled"; $SharePoint = "Disabled"; $Lync = "Disabled"; $Office = "Disabled"; $WebApps = "Disabled"

We retrieve the assigned license and make note of which options are actually enabled for the user:

(Get-MsolUser -User $Upn).Licenses[0].ServiceStatus | ForEach {

If ($_.ServicePlan.ServiceName -eq "EXCHANGE_S_ENTERPRISE" –and $_.ProvisioningStatus -ne "Disabled" { $Exchange = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "SHAREPOINTENTERPRISE" –and $_.ProvisioningStatus -ne "Disabled") { $SharePoint = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "MCOSTANDARD" –and $_.ProvisioningStatus -ne "Disabled") { $Lync = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "OFFICESUBSCRIPTION" –and $_.ProvisioningStatus –ne "Disabled") { $Office = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "SHAREPOINTWAC" -and $_.ProvisioningStatus -ne "Disabled") { $WebApps = "Enabled" } }

Next, we create an array and populate the variable with the results from the license audit.  In this example, Office is not added as a disabled option since we will be enabling this service for all users:

$DisabledOptions = @()

If ($Exchange -eq "Disabled") { $DisabledOptions += "EXCHANGE_S_ENTERPRISE" }

If ($SharePoint -eq "Disabled") { $DisabledOptions += "SHAREPOINTENTERPRISE" }

If ($Lync -eq "Disabled") { $DisabledOptions += "MCOSTANDARD" }

#If ($Office -eq "Disabled") { $DisabledOptions += "OFFICESUBSCRIPTION" }

If ($WebApps -eq "Disabled") { $DisabledOptions += "SHAREPOINTWAC" }

Now we can create the license option variable which assigns all services except those that were not already enabled:

$LicenseOptions = New-MsolLicenseOptions –AccountSkuId "tenant:ENTERPRISEPACK" –DisabledPlans $DisabledOptions

And finally, we apply the license to the user account:

       Set-MsolUserLicense –User $Upn –LicenseOptions $LicenseOptions

These same concepts can be used in a number of different scenarios for which only certain O365 license options must be bulk enabled.  For a more complex scenario and some advanced license reconciliation concepts, please refer to Bulk Migrate Office 365 Licenses.  RjZ

UPDATE:  I received feedback that this script may not work properly when more than one license or stand-alone SKU is assigned.  Therefore, I have revised it to detect and evaluate the E3 license only, even if other SKUs are assigned.  This is easily changed in the script to look for other SKUs too.  I have also included logic for Yammer.

Enable-LicenseOptions.zip

To begin, I created a file share on the Exchange 2010 CAS where IDM can write its export files.  Now, each time new users are created in AD, the data is written to CSV files on the IDM share.  The contents of the export file include CN (Name), UserPrincipalName (Upn), and EmployeeType.  The employee type (or a similar identifier) will be used to determine which O365 license gets assigned.

Now, let's begin developing the script.  First, we need to connect to O365.  The script will be running as a scheduled task, so, I need to include the O365 credentials without prompts.  I describe the steps for creating a secure password file in a previous post:

$Username = "admin@domain.onmicrosoft.com"

$Password = Get-Content c:\o365\remoteps.pwd | ConvertTo-SecureString

$Credential = New-Object System.Management.Automation.PSCredential($Username,$Password)

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://ps.outlook.com/powershell" -Credential $Credential -Authentication Basic -AllowRedirection

$ImportResults = Import-PSSession $Session

Import-Module MSOnline

Connect-MSOLService -Credential $Credential

I'll set a timestamp that can be used to identify each processing run:

$TimeStamp = Get-Date -Format "yyMMddhhmmss"

Next, well read all the CSV export files created by the identity management solution and write the aggregated results into a temporary file:

Get-ChildItem -Path c:\IDM\*.csv | ForEach { Import-Csv $_ } | Export-Csv -NoTypeInformation "c:\IDM\$TimeStamp.tmp"

Once all the CSV export files are processed, we'll move the original files to a Processed folder along with any old log files:

Move-Item "c:\IDM\*.csv" "c:\IDM\Processed"

Move-Item "c:\IDM\*.log" "c:\IDM\Processed"

And then we'll create a new export file and log file to save our provisioning results:

$ExportFile = "c:\IDM\$TimeStamp.csv"

"CN,EmployeeType,UserPrincipalName" | Out-File $ExportFile

$LogFile = "c:\IDM\$TimeStamp.log"

Now, let's do some work!  We will import the temporary CSV file that contains the aggregated data from each of the IDM export files and set some variables:

Import-Csv "c:\IDM\$TimeStamp.tmp" | ForEach {

$Name = $_.CN; $Type = $_.EmployeeType

$Upn = $_.UserPrincipalName

$CheckMailbox = $null; $CheckMailUser = $null

For each user, we will run Get-Mailbox to check if a mailbox already exists in O365.  If a mailbox cannot be found, the cmdlet will error out and the $CheckMailbox variable will remain null.

$CheckMailbox = Get-Mailbox $Upn

If there is no mailbox already provisioned for the user, we run Get-MsolUser to check if the account has been mail-enabled and synchronized to O365.  Once again, if the account has not been successfully mail-enabled, then the cmdlet will error out and the $CheckMailUser variable will remain null.

If ($CheckMailbox -eq $null) {

  $CheckMailUser = Get-MsolUser -User $Upn

If the new account has been successfully mail-enabled, then we'll set the usage location and assign an O365 license.  In this example, I am using the EmployeeType column from the IDM export files to determine whether the user gets an Exchange Standard license or a Kiosk license.  We'll also write the results to a log file:

If ($CheckMailUser -ne $null) {

   Set-MsolUser -User $Upn -UsageLocation US

   If ($Type -eq "E") {

     Set-MsolUserLicense -User $Upn -AddLicenses "tenant:EXCHANGESTANDARD"

     "SUCCESS: New user account provisioned with Plan1 mailbox [$Upn]" |
     Out-File $LogFile -Append }

   If ($Type -eq "N") {

     Set-MsolUserLicense -User $Upn -AddLicenses "tenant:EXCHANGEDESKLESS"

     "SUCCESS: New account provisioned with Kiosk mailbox [$Upn]" |
     Out-File $LogFile -Append }

After assigning the license, we will run Test-MapiConnectivity which seems to help initialize newly created mailboxes:

  Test-MapiConnectivity $Upn }

Finally, we'll write data to the log file if the account was not mail-enabled.  It's possible, however, that DirSync has not yet run for the newly created account.  So, instead of discarding the user, I will write the data to a new CSV file so that it can be processed again.

  Else {

    "ERROR: New account not synchronized to O365 [$Upn]" | Out-File
    $LogFile -Append

    "$Name,$Type,$Upn" | Out-File $ExportFile -Append } }

I will also write to the log if an O365 mailbox already existed for the user.

Else { "ERROR: O365 mailbox already exists for new user account [$Upn]" |
Out-File $LogFile -Append } }

As a bonus, we can email the log file to a user (or group of users) for review:

$SmtpServer = "smtp.domain.com"

$Smtp = New-Object Net.Mail.SmtpClient($SmtpServer)

$SmtpFile = New-Object Net.Mail.Attachment($LogFile)

$SmtpMsg = New-Object Net.Mail.MailMessage

$SmtpMsg.From = "admin@domain.com"

$SmtpMsg.To.Add("user@domain.com")

$SmtpMsg.Subject = "New Mailbox Provisioning"

$SmtpMsg.Body = "Attached is the latest O365 mailbox provisioning log."

$SmtpMsg.Attachments.Add($SmtpFile)

$Smtp.Timeout = "30000"

$Smtp.Send($SmtpMsg)

And as a best practice, we will gracefully disconnect our remote PowerShell session.  I am also deleting our temporary file and "releasing" the log file.

Remove-PSSession -Session $Session

Remove-Item "c:\IDM\$TimeStamp.tmp"

$SmtpFile.Dispose()

Now, the script can be run periodically as a scheduled task.  Here is a summary of what it actually does...

On subsequent runs, the script will read any new CSV files IDM has exported to the share, plus the CSV created for any failed or skipped users... and the whole process repeats.  RjZ

AutoProvisionMailbox.zip

My first instinct was to parse through the 1,600 lines of their current script and look for ways to streamline and improve it.  However, I instead decided to re-write the script from scratch using PowerShell…

First, let’s define a few variables.  I set “ErrorActionPreference” so that the script would continue if it encountered any exit errors:

    $ErrorActionPreference = "Continue"

I also define the local computer name so that we can include it in the results:

    $strComputer = $env:ComputerName

Next, I enumerate all the drive letters and store them in a collection variable:

    $colDrives = Get-PSDrive -PSProvider Filesystem

Now, let’s begin doing some work.  For each drive letter I need to output the permissions of every file and folder on the volume.  The easiest way to walk the file system is to specify the starting root directory and use “Get-ChildItem” with the “Recurse” parameter.  I also use the “LiteralPath” parameter in case file or folder names include special characters, such as square brackets or ampersands:

    ForEach ($DriveLetter in $colDrives) {
    $StartPath = "$DriveLetter`:\"
    Get-ChildItem -LiteralPath $StartPath –Recurse }

Next, we can use “Get-Acl” and expand the “Access” column to return all the data related to the ACE:

    Get-Acl | Select * -Expand Access

But, wait… I’ve discovered a problem!  Get-Acl crashes if I try to enumerate permissions on a file or folder which contains special characters.  Unfortunately, Get-Acl does not support the LiteralPath parameter, which is a well-documented shortcoming.  So, we will need to “escape” any special characters in the path name.

I found several examples of various subroutines and functions which parse the path name and escapes special characters.  But, I couldn’t help thinking these methods simply added overhead to the script.  Therefore, I changed my approach and instead used Get-Item (which does support the LiteralPath parameter) and the GetAccessControl method which returns the same information as Get-Acl:

    ForEach {
    $FullPath = Get-Item -LiteralPath (Get-Item -LiteralPath $_.PSPath)
    (Get-Item -LiteralPath $FullPath).GetAccessControl() }

Now, with all our data exposed, we can begin to select the columns and transform them into the required export format.  My customer had specific guidelines for how the data should be labeled and formatted.  But, this can obviously be changed to suit other requirements.

In the first column, we’ll write the server name:

    Select @{N='Server Name';E={$strComputer}}

Then we’ll write the full path of the file or folder:

    @{N='Full Path';E={$FullPath}}

If the object is a directory, write “D”.  Otherwise, write “F”:

    @{N='Type';E={If($FullPath.PSIsContainer -eq $True) {'D'} Else {'F'}}}

Write the owner:

    @{N='Owner';E={$_.Owner}}

Write each of the accounts associated with the ACE:

    @{N='Trustee';E={$_.IdentityReference}}

For each ACE, write whether the permissions are inherited:

    @{N='Inherited';E={$_.IsInherited}}

Write the inheritance flags:

    @{N='Inheritance Flags';E={$_.InheritanceFlags}}

Write the propagation flags:

    @{N='Ace Flags';E={$_.PropagationFlags}}

Write the access control type:

    @{N='Ace Type';E={$_.AccessControlType}}

Write the permissions:

    @{N='Access Masks';E={$_.FileSystemRights}}

And finally, we’ll stream the results into an export file whose name includes the server and drive letter.  My customer also asked that each column be separated by “|” as a delimiter:

    Export-CSV -NoTypeInformation -Delimiter "|" -Path "$strComputer`_$DriveLetter.csv"

That's it.  The resulting script is very fast and very efficient.  What used to take 3 days now runs in just over 1 hour and utilizes minimal resources.  The only drawback is that the script depends on expanded capabilities of PowerShell v2 which had to be installed on some of the servers.  RjZ

AuditFilePermissions.zip

Office 365 includes several default RBAC roles which allow end-users to access ECP and manage their own account properties or advanced mailbox features.  A summary of the built-in roles can be found at https://help.outlook.com/en-us/140/Dd207272.aspx.  An O365 administrator can also enable and disable certain roles to control what properties and/or features a user can manage.  There are several roles, however, that may not provide the desired functionality in Office 365.  For example, allowing a federated user to modify their own contact information results in an error since that information is synchronized from on-premise.  Similarly, a customer may not want users managing their own distribution groups, or may have policies which forbid connected mailboxes.  In these cases, the default user role assignment policy can be customized to remove many of the RBAC roles.

1. Logon to O365 and administrator
2. On the Admin Overview page, click Manage under Exchange Online
3. From ECP, select Roles & Auditing
4. Select Default Role Assignment Policy and click Details
5. From the list of RBAC roles, uncheck the options/features that are not required and click Save.

In my customer’s case, we unchecked all options except MyBaseOptions.  This allowed a user to view their contact information, but not make any changes.  In addition, it removed most of the other advanced settings and self-service features.  However, we discovered it does not remove the user’s ability to forward incoming email to alternate address.  My customer had a strict policy related to automatic email forwarding, so this feature also had to be removed and controlled as a separate management role. We accomplished this by customizing the RBAC roles in O365 using a remote PowerShell session.

1. Export MyBaseOptions management role entries for reference:
   Get-ManagementRoleEntry MyBaseOptions\* | ConvertTo-Html > C:\MyBaseOptions.htm
2. Copy the existing MyBaseOptions management role as new MyMailForwarding Role:
   New-ManagementRole –Parent MyBaseOptions –Name MyMailForwarding
3. Copy the existing MyBaseOptions management role as a new MyMailbox role:
   New-ManagementRole –Parent MyBaseOptions –Name MyMailbox
4. Remove all Set-Mailbox parameters (which include mail forwarding permissions) from the new MyMailbox role:
   Remove-ManagementRoleEntry MyMailbox\Set-Mailbox
5. Add Set-Mailbox parameters back to MyMailbox role except those associated with mail forwarding:
   Add-ManagementRoleEntry MyMailbox\Set-Mailbox –Parameters AcceptMessagesOnlyFrom, AcceptMessagesOnlyFromDLMembers, AcceptMessagesOnlyFromSendersOrMembers, ErrorAction, ErrorVariable, ExternalOofOptions, GrantSendOnBehalfTo, Identity, Languages, MailTip, MailTipTranslations, OutBuffer, OutVariable, Password, RejectMessagesFrom, RejectMessagesFromDLMembers, RejectMessagesFromSendersOrMembers, RequireSenderAuthenticationEnabled, UserCertificate, UserSMimeCertificate, WarningAction, WarningVariable

Now we modify the Default Role Assignment Policy so that includes only the new MyMailbox role which we’ve customized.  It includes all the same settings as MyBaseOption, minus the mail forwarding feature.

1. Logon to ECP as administrator account
2. Click Roles & Auditing along the left
3. Click User Roles along the top
4. Select “Default Role Assignment Policy” and click Details
5. Uncheck all management roles except MyMailbox and click Save

With the customizations complete and the new policy defined, all O365 users now have only the bare minimum of features approved by the customer.  However, we all agreed that there may be exceptions where mail forwarding must be enabled for select accounts.  Therefore, we created an new role assignment policy which could selectively be applied to specific mailboxes.

1. Logon to ECP as administrator account
2. Click Roles & Auditing along the left
3. Click User Roles along the top
4. Under Role Assignment Policies, click New
5. Name the new policy Enable Mail Forwarding and provide a description
6. Select only MyBaseOptions role which now contains both MyMailbox and MyMailForwarding
7. Click Save

To allow mail forwarding for specific users, the new Enable Mail Forwarding policy can be applied to their mailbox.

1. Logon to ECP as administrator account
2. Click Users & Groups along the left
3. Click Mailboxes along the top
4. Locate and select a specific user and click Details
5. Expand Mailbox Settings
6. Change the role assignment policy to Enable Mail Forwarding
7. Click Save

These instructions reflect a real-world scenario in which RBAC roles in O365 had to be customized.  They outline the steps to explicitly manage email forwarding, but can be applied to any situation where individual features must be enabled or disabled.  RjZ

The script will first need to connect to O365:

$Credential = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://ps.outlook.com/powershell" -Credential $Credential -Authentication Basic –AllowRedirection

$ImportResults = Import-PSSession $Session

The groups which contain the users that should be enabled for POP3 and/or IMAP need to be identified.  A remote PowerShell session includes the Get-Group cmdlet.  But, this only seems to return mail-enabled groups and distribution lists.  In my case, the POP3 and IMAP groups are security groups synchronized to O365.  Therefore, I had to download and install the Microsoft Online Services Module for PowerShell which gave me access to Get-MSOLGroup cmdlet to query security groups.  In order to utilize the MSOL cmdlets, I must now import and connect the module from within the script:

Import-Module MSOnline

Connect-MSOLService -Credential $Credential

With the MSOL module loaded, I can now query the O365 security groups (in my case “POP3-Users” and “IMAP-Users”) whose members should be enabled for POP3 and/or IMAP access:

$PopGroup = Get-MSOLGroup -All | Where-Object {$_.DisplayName -eq "POP3-Users"}

$ImapGroup = Get-MSOLGroup -All | Where-Object {$_.DisplayName -eq "IMAP-Users"}

And from the groups, we can identify the individual members:

$EnablePOP = Get-MSOLGroupMember -GroupObjectId $PopGroup.ObjectId -All | Select-Object -ExpandProperty DisplayName

$EnableImap = Get-MSOLGroupMember -GroupObjectId $ImapGroup.ObjectId -All | Select-Object -ExpandProperty DisplayName

Finally, we will collect all the mailboxes currently provisioned in O365:

$Mailboxes = Get-Mailbox -ResultSize Unlimited

With all the variables defined, we will now increment through each of the mailboxes and determine if the account is a member of the POP3 or IMAP group.  If we find a match in either group, then the appropriate mailbox protocol(s) will be enabled.  Otherwise, both POP3 and IMAP will be disabled:

ForEach ($Mailbox in $Mailboxes) {
  If ($EnablePop -Contains $Mailbox) {
      $Mailbox | Set-CASMailbox -PopEnabled $True }
  Else {
      $Mailbox | Set-CASMailbox -PopEnabled $False }
  If ($EnableImap -Contains $Mailbox) {
      $Mailbox | Set-CASMailbox -ImapEnabled $True }
  Else {
      $Mailbox | Set-CASMailbox -ImapEnabled $False }}

    As a best practice, we will disconnect from the remote session when the script is complete:

Remove-PSSession $Session

The functionality of the script is now complete and should work great by running it manually and entering O365 admin credentials when prompted.  However, I want the script to run automatically as a daily scheduled task without having to enter credentials.  Therefore, I must securely store my password so that I can call it into the script.  The following commands are not part of the final script and should be typed in a local PowerShell session while logged on to the computer as the user account which will run the scheduled task.  Only the account that creates the password file can decrypt the password file.  In my case, I’m logged on to the machine as Administrator and that will be the account used to run the scheduled task:

$Credential = Get-Credential

$Credential.Password | ConvertFrom-SecureString | Set-Content "c:\o365\remoteps.pwd"

I’ll modify the script to retrieve the stored password instead of prompting for credentials:

$Credential = Get-Credential

$Username = "o365admin@domain.onmicrosoft.com"

$Password = Get-Content c:\o365\remoteps.pwd | ConvertTo-SecureString

$Credential = New-Object System.Management.Automation.PSCredential($Username,$Password)

We should now be able to run the script manually with no authentication prompts.  So, let's create a new scheduled task:

1. From Administrative Tools, run Task Scheduler and select Create Task.
2. On the General tab, type a friendly name and description for the task.
3. Click Change User or Group button and specify the account under which the secure O365 password was created.
4. Select “Run whether user is logged on or not” and enable “Run with highest privileges”.
5. On the Triggers tab, click New and define a schedule for when the task will run.
6. On the Actions tab, click New and type “powershell.exe” as the Program/Script name and add the following arguments:  -file “c:\o365\ScriptName.ps1”
7. Save Scheduled Task

I have the script scheduled to run from the on-premise Exchange 2010 coexistence server.  However, it can be scheduled to run from any computer on which PowerShell and the MSOL module can be installed.  RjZ

DisablePopImap.zip

• Logon as Domain Admin and take ownership of Deleted Objects container:
  dsacls “CN=Deleted Objects,DC=domain,DC=com” /takeownership
  
• Grant delegated user/group permissions (List, Read, Write) to view and restore deleted objects:
  dsacls “CN=Deleted Objects,DC=domain,dc=com” /g domain\accountname:LCRPWP
  
• Using ADUC, grant user/group rights to reanimate tombstone:
• Right-click domain root and select Properties
• On the Security tab, click Advanced
• Click Add and select user/group account
• Allow the Reanimate Tombstones permission and click OK

A couple of additional notes worth mentioning…
Delegated permissions only seem to apply to objects deleted after configuration; objects deleted before configuration must be restored by Domain Admin. Also, delegated administrators must have permissions on the source/target OU where deleted objects will be restored. In my customer's case, they already had a well-defined OU administration model. So, while all delegated administrators could view AD RB, they could only restore objects deleted from their own OU. Perfect! RjZ