Just can't get enough of IT

The PowerShell script to Set mailbox quotas at database or mailbox level the simple way has been updated to Version 1.4.

The code has been refactored to functions and has received some PowerShell hygiene patters.

Please report any issues directly at Github.

If you like the script, please rate the script at TechNet Gallery.

Enjoy!

The PowerShell script to purge Exchange Server and IIS log files has been updated to version 2.0.

Release 2.0 allows for copying of files that will be deleted to be copied to a central file repository. The script will create a folder per server and the full log file folder structure will be preserved.

The next release will contain an option to compress the copied log files.

Added code:

function Copy-LogFiles {
  [CmdletBinding()]
  param(
    [string]$SourceServer,
    [string]$SourcePath,
    $FilesToMove
  )

  if($SourceServer -ne '') { 

    # path per SERVER for zipped archives
    $ServerRepositoryPath = Join-Path -Path $RepositoryRootPath -ChildPath $SourceServer

    # subfolder used as target for copying source folders and files
    $ServerRepositoryLogsPath = Join-Path -Path $ServerRepositoryPath -ChildPath $LogSubfolderName

    $ServerRepositoryPath = Join-Path -Path $RepositoryRootPath -ChildPath $SourceServer

    if(!(Test-Path -Path $ServerRepositoryPath)) {
      # Create new target directory for server, if does not exist
      $null = New-Item -Path $ServerRepositoryPath -ItemType Directory -Force -Confirm:$false
    }

    foreach ($File in $FilesToMove) {
      # target directory
      $targetDir = $File.DirectoryName.Replace($TargetServerFolder, $ServerRepositoryLogsPath)

      # target file path
      $targetFile = $File.FullName.Replace($TargetServerFolder, $ServerRepositoryLogsPath)
      
      # create target directory, if not exists
      if(!(Test-Path -Path $targetDir)) {$null = mkdir -Path $targetDir}

      # copy file to target
      $null = Copy-Item -Path $File.FullName -Destination $targetFile -Recurse -Force -Confirm:$false -ErrorAction SilentlyContinue

    }-Force   
    
    if($ZipArchive) {
      # zip copied log files
      #
      <# NOT FULLY TESTED YET 
      $Archive = Join-Path -Path $ServerRepositoryPath -ChildPath $ArchiveFileName
      $logger.Write(('Zip copied files to {0}' -f $ArchiveFileName))

      if(Test-Path -Path $Archive) {Remove-Item $Archive -Force -Confirm:$false}

      Add-Type -AssemblyName 'System.IO.Compression.FileSystem'
      [IO.Compression.ZipFile]::CreateFromDirectory($ServerRepositoryLogsPath,$Archive)

      #>
    } 
  }  
}

Note

• The script utilizes the GlobalFunctions PowerShell module which needs to be installed first.

Links

• Release 2.0 at Github:
• Original blog post: https://www.granikos.eu/en/justcantgetenough/PostId/208/purge-exchange-server-and-iis-log-files

Social

• Twitter @stensitzki
• LinkedIn
• Xing

Problem

You can block an user from logging on to Office 365 by setting the BlockCredential attribute to $true.

Set-MsolUser -UserPrincipalName myuser@mcsmemail.de -BlockCredential $true

But the MSOL user attribute is reverted to $false, when ADD Connect synchonization cycle runs.

This happens, because the local Active Directory attribute accountEnabled is used to controll the BlockCredential attribute in Azure AD.

Solution

If your IT operation requires the ability to have enabled users in your local Active Directory infrastructure and you need to prevent logon to cloud services you need to prevent the accountEnabled attribute from being synchronized to Azure AD. This might not necessarily be a general requirement during normal operations, but might be useful while doing a Proof-of-Concept.

Just exclude the attribute from the Azure Active Directory connector in the Synchronization Service Manager.

The following script disables all users excluding

• Users following a specific naming pattern
• Users listed in a string array

# Userfilter
$UserExceptions = ("Sync_SYNC01_add98768492f@mcsmemail.onmicrosoft.com","SPO-SRV-ACCOUNT@mcsmemail.de","SynchedAdmin@mcsmemail.de")

# Fetch synchronized users 
$DomainAccounts = Get-MsolUser -EnabledFilter EnabledOnly -MaxResults 5000 | Where-Object -Property LastDirSyncTime -ne $null

# Select synchronized users not following the pattern ADM*@mcsmemail.de (admin accounts in this case)
$DomainAccountsWithoutAdmins =  $DomainAccounts | Where-Object -Property UserPrincipalName -notlike "ADM*@mcsmemail.de"

# Exclude accounts listed in $UserExceptions
$DomainAccountsWithoutAdminsFiltered = $DomainAccountsWithoutAdmins | Where-Object -Property UserPrincipalName -NotIn $UserExceptions
 

# Now block cloud logon for all filtered users
ForEach ($User2Block in $DomainAccountsWithoutAdminsFiltered) {
  Write-Host ('Disabling User: {0}.UserPrincipalName)' -f $User2Block)
  Set-MsolUser -UserPrincipalName $User2Block.UserPrincipalName -BlockCredential $true
}

Enjoy Office 365.

The PowerShell module GlobalFunctions got updated to Version 2.0. This module is used by some of my PowerShell scripts which utilize centralized logging. 

The new release contains the first functions required for some upcoming scripts for managing on-boarding process for joiners and the off-boarding process for leavers for companies utilizing Office 365.

Changes

• File encoding switch from UTF8 to Unicode
• New functions
  • Format-SpecialCharactersUpperCase
  • New-RandomPassword

Notes

The New-RandomPassword functions is based on Simon Wahlin's script published here: https://gallery.technet.microsoft.com/scriptcenter/Generate-a-random-and-5c879ed5

Links

• Original blog post: https://www.granikos.eu/en/justcantgetenough/PostId/210/globalfunctions-shared-powershell-library
• Easiest install via PowerShell Gallery: https://www.powershellgallery.com/packages/GlobalFunctions
• Report issues at Github: https://github.com/Apoc70/GlobalFunctions

As an Exchange administrator you normally perform tasks by executing PowerShell scripts. Some of these scripts are executed automatically, some are run manually as these scripts require more attention.

Think about a completely different approach. Have you ever thought about administrating Exchange Server or your Exchange Online instance using your voice?

Thanks to Alexa skills we can do something like

"Alexa, ask Exchange Assistant to create a new mailbox for John Doe"

"Alexa, is the CEO's mailbox in good shape?"

Or run something more complicated

"Alexa, start Exchange to setup 5 new Exchange servers, please"

Sounds like magic, right?

Solution

As a solution we use the following technologies:

• Alexa custom skills extension for Exchange
• Azure subscription supporting
  • Azure Web API
  • Azure Automation
• Azure Hybrid Runbook Worker

The Azure Hybrid Runbook Worker enables you to execute PowerShell runbooks in your local infrastructure to manage local ressources.

How does it work

The solution consists of a Visual Studio Solution acting as an Alexa skill endpoint. The configured intents connect to your Azure Automation webhooks and trigger the execution of preconfigured PowerShell automation runbooks.

These runbooks can either run againt Azure resources or against your local infrastructure. Automation of your local infrastructure requires the setup of the Azure Hybrid Runbook Worker components.

The following diagram illustrates the functionality.

Requirements

• You need to have an Amazon Alexa device
• You need to have an Amazon Alexa Developer account
• You need to have an active Microsoft Azure subscription
• You need to deploy the Hybrid Runbook Worker component in your local infrastructure, if you want to automate your local infrastrucute

Preparation

The solution utilizes the Azure4Alexa and AlexaSkillsSet.NET projects available on Github. Currently the approach requires some manual steps and Visual Studio knowledge, as you want to deploy your own Alexa custom application. This is primarily driven due to security demands. The Hybrid Runbook Worker can access your local infrastructure. So you went to be in charge of the credentials used to access your infrastructure.

1. Clone the Visual Studio solution from Github (https://github.com/Apoc70/ExchangeSpeechAssistant)
2. Follow the description provided here to setup your personal Alexa developer account and to get your Azure trial subscription to host the application
3. Publish the Visual Studio solution as an intital endpoint to setup your Alexa custom skill
   This results in a simple web page demonstrating the new Azure Web App
   
4. Modify the AlexaConstants.cs to use your Application Id
5. Re-Publish the Visual Studio solution with your custom Application Id
6. Prepare your local infrastructure for the use with Hybrid Runbook Worker
   1. Installing Hybrid Runbook Worker
   2. Create a Runbook Automation Account
      
   3. Create a runbook for whatever action you want to execute
      

Start enjoying how your administrator's can orchestrate your Exchange Server environment.

Links

• Alexa Developer Account
• AlexaSkillsSet.NET (implemented by Alexa4Azure)
• Additonal Notes

Enjoy your wonderful life with Exchange :-)