Making your PowerShell script require a particular version of PowerShell to be installed.

Making your PowerShell script require a particular version of PowerShell to be installed.

A common mistake made in a lot of PowerShell scripts is that not all cmdlets are supported across all installed versions of PowerShell.

So how do you ensure that the script you have created can only be executed on a machine that supports the cmdlets? Simple!!!

By using one of the below will ensure that the client must met that version or be high;
#Requires -Version 3.0
#Requires -Version 4.0
#Requires -Version 5.0

So here is an example of a cmdlet that is only supported in version 5, it provides a horrible error message which doesn’t help the end-user.

And heres is an example of the same cmdlet but with #Requires -version 5.0

With this simple line you can prevent your scripts from being executed against machines that dont have the require PowerShell version installed.

Regards
The Author @ Blogabout.Cloud

Install-Module : The term ‘Install-Module’ is not recognized as the name of a cmdlet, function, script file, or operable program

Install-Module : The term ‘Install-Module’ is not recognized as the name of a cmdlet, function, script file, or operable program

Recently, I was trying to use Install-Module cmdlet to install a required module for some testing on a client machine however I ran into the following error

Install-Module: The term ‘Install-Module’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1Install-Module MSOnline. CategoryInfo : ObjectNotFound: (Install-Module:String) [], CommandNotFoundException FullyQualifiedErrorId : CommandNotFoundException

The error looks like below:

Install-Module : The term ‘Install-Module’ is not recognized as the name of a cmdlet, function, script file, or operable program

The error usually comes, if your PowerShell is not upto date. The major version of PowerShell should be equal or greater than 5. You can run the below cmdlets to check the PowerShell version.


1
$PSVersionTable.PSVersion

My PowerShell major version was 4.

To solve the error the following steps was taken to resolve the issue.

Download Windows Management Framework 5.1

Here make sure to choose Win8.1AndW2K12R2-KB3191564-x64.msu if you have Windows server 2012 or 2012 R2 machine.

Install-Module : The term 'Install-Module' is not recognized as the name of a cmdlet, function, script file, or operable program
Install-Module : The term ‘Install-Module’ is not recognized as the name of a cmdlet, function, script file, or operable program

Download and install Download Windows Management Framework 5.1, then it will ask to restart the machine-like below:

The term 'Install-Module' is not recognized as the name of a cmdlet
The term ‘Install-Module’ is not recognized as the name of a cmdlet

Regards
The Author – Blogabout.Cloud

ForEach Installed PowerShell Module Thanos Wipe.

ForEach Installed PowerShell Module Thanos Wipe.

In recent times I have been playing with a number of PowerShell modules and now decided to have a bit of a clean up or in the world of PowerShell and Marvel Install-Thanos

Image result for thanos

This process couldnt be any easier if I try,


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$Array = @(Get-InstalledModule)

   Foreach ($Module in $Array)
   {
     $ModuleCheck = Get-InstalledModule -name $Module.Name -ErrorAction SilentlyContinue  

     if ($ModuleCheck) {
     Write-Host 'Info: Detected an installation of the',$Module.Name,'Module' -ForegroundColor Green
     $Module = Get-Module -Name $Module.Name -ListAvailable
       
     # Identify modules with multiple versions installed
     Write-Host 'Info: Removing',$Module.Name,'Module' -ForegroundColor Yellow
     Uninstall-Module -Name $Module.Name -Force
   }
   }

And just like magic, all your PowerShell Modules should disappear like the Spiderman.

Regards
The Author – Blogabout.Cloud

Changing Window Updates setting using PowerShell

Changing Window Updates setting using PowerShell

In this post, I will look at how to modify the required Registry Keys for Windows Server 2012R2 / 2016 Update settings using PowerShell. PowerShell is one of the gems within Microsoft and enables us to work with systems without the help of a GUI.

Windows always looks at registry keys located in the following hive:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

Typically there is a key named ‘NoAutoUpdate’ with a value in the range 2-5, and have the following meaning:

– 1 = Disable Updates – Only supported on Windows 2012 R2.
– 2 = Notify before download.
– 3 = Automatically download and notify of installation.
– 4 = Automatically download and schedule installation. Only valid if values exist for ScheduledInstallDay and ScheduledInstallTime.
– 5 = Automatic Updates is required and users can configure it.

But if there is a ‘NoAutoUpdate’ key with the value of ‘1’, no updates will be processed by Windows.

You can change the registry key with the help of Powershell directly:

1
Set-ItemProperty -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU -Name NoAutoUpdate -Value 3

Regards
The Author – Blogabout.Cloud

Say goodbye to your legacy PSGallery modules with Get-InstalledModuleUpdate.ps1

Say goodbye to your legacy PSGallery modules with Get-InstalledModuleUpdate.ps1

Working as a Microsoft Cloud Consultant sometimes its hard to keep update to all the latest release of the required PowerShell modules installed on your client machine. Would it be nice if there was a script that took all that pain away?

Say hello to Get-InstalledModulesUpdate.ps1 script

Image result for groot wave

This script is based off my Microsoft Teams Detection script but instead of looking at just that module. I am grabbing all your installed PowerShell module and checking each one against the PSGallery

Module checking

As you can see from my screen shot the script has looked at each modules installed on my client machine and compared to the online version. If a legacy module was detected the update process would start to remove the old version and install the latest from the gallery.

This script is available via my Github or via this site.

Download

Get-InstalledModulesUpdates.ps1 (53 downloads)

Change Log

Version 1.0 – Features

  • Initial release

Version 1.1 – Features

  • Minor updates to code structure

Version 1.2

  • Minor updates to code structure

Version 1.3

  • Minor updates to code structure
  • Transcript of the changes made and dumped to Desktop.

Regards

The Author – Blogabout.Cloud

Working with Variables located in PowerShell Functions

Working with Variables located in PowerShell Functions

I have been recently working on updating a number of my PowerShell scripts and ran into an issue where my variables were unavailable within a function. The resolution for this is making the variables globally available to all the function(s) that are contained within your script.

So, as you can see below. I have configured my script blocks into Functions and converted the Parameter variables into $Global: variables. This will allow the Get-MailMessage function to use the $Global: variables within its own function

Without $Global:
With $Global:

However, there is one more step required to ensure that the variables can use the globally defined variables. I have a configure region within my script that contains all my defined variables and in here I have put for example $Global:Variable = $Global:Variable

$Global:Variables = $Global:Variables

As you can see from above image the variables located in New-MailMessage function are not highlighted in yellow.

Tools of the trade

The reason for the highlighted variables within my script, I use a tool called PowerShell ISE http://www.powertheshell.com. There is a slight cost but well worth it if you are regularly building scripts.

Regards

The Author – Blogabout.Cloud

The Great Wall in Microsoft Teams – Information Barrier in Preview

The Great Wall in Microsoft Teams – Information Barrier in Preview

Another great feature now become available in Microsoft Teams Preview – Information Barrier. This enables organization to prevent communicate between Teams within their own Office 365 tenant. The information barrier groups cannot be applied across tenants and using bots to add users is not supported in version 1. Information barrier policies also prevent lookups and discovery. This means that if you attempt to communicate with someone you should not be communicating with, you will not find that user in the people picker.

You might want to use information barriers in situations like these:

  • A team must be prevented from communicating or sharing data with a specific other team.
  • A team must not communicate or share data with anyone outside of the team.

In order to manage the Information Barrier policy you will need to use the Security and Compliance Centre (SCC) PowerShell cmdlets

The information barrier features is in private preview. When these features are generally available, they’ll be included in the following subscriptions;

  • Microsoft 365 E5
  • Office 365 E5
  • Office 365 Advanced Compliance
  • Microsoft 365 E5 Compliance

Microsoft Teams is firmly becoming the powerhouse that was sold at its initial launch and I can only this product becoming adopted a lot more by organisations

Regards

The Author – Blogabout.Cloud

Microsoft Teams module now in GA

Microsoft Teams module now in GA

Its been a long road but Microsoft Teams PowerShell module version 1.0.0 is now available in GA. Microsoft has been working very hard in creating this module and have removed/introduction features into this release. So lets have a look at what we now can and cannot do with Microsoft Teams

So what’s removed?

So Microsoft have removed the following cmdlets

  • Get-TeamFunSettings
  • Get-TeamGuestSettings
  • Get-TeamMemberSettings
  • Get-TeamMessagingSettings
  • Set-TeamFunSettings
  • Set-TeamGuestSettings
  • Set-TeamMemberSettings
  • Set-TeamMessagingSettings

But do not fear, as the same functionality of these cmdlets have been integrated into Get-Team and Set-Team.

So what’s new?

  • Connect-MicrosoftTeams allows you to specify a Teams Government Environment (-TeamsEnvironmentName) that your organization is homed in.
  • Get-Team allows you to specify new filter and selection criteria to identify specific teams based off of new criteria, including the Visibility or Archived state of the teams.

So its time to start playing with the Teams module and seeing what interesting scripts can be generated.

Please Note: It is recommended to uninstall any previous version you may have installed. So check out this previous blog post i created

http://www.blogabout.cloud/2018/09/240/


Regards
The Author – Blogabout.Cloud

The pain in the a** that is special characters. Understanding what is and isnt supported when migrating to the Microsoft Cloud.

The pain in the a** that is special characters. Understanding what is and isnt supported when migrating to the Microsoft Cloud.

Related image

So in recent months, I have been working a number of large organisation that have issues with special characters that are affecting their migration to the Microsoft Cloud. Yes, I IDFix does an excellent job of correcting a lot of the issues. However, in recent time I have been rolled into customer sites to troubleshoot and report on special characters contained in Distribution Lists and Shared Mailboxes which cannot be migrated to Exchange Online.

What special characters are supported in Office 365?

So first of all, what is and is not supported. The below table gives an excellent break down what the character can be supported in UserNames, Password and Email Addresses.

Allowed In
Character NameCharacterUser NamePasswordEmail Address
Accent`NoYesNo
Ampersand&NoYesNo
Angle Brackets< >NoYesNo
ApostropheNoYesYes***
Asterisk*NoYesNo
At Symbol@NoYesNo
Backslash\NoYesNo
Braces[ ]NoYesNo
Brackets{ }NoYesNo
Circumflex^NoYesNo
Colon:NoYesNo
Comma,NoYesNo
Dollar Sign$NoYesNo
Equal Sign=NoYesNo
Exclamation Point!NoYesNo
HyphenYes*YesYes*
Number Sign#NoYesNo
Parentheses( )NoYesNo
Percent Symbol%NoYesNo
Period.Yes*YesYes*
Pipe|NoYesNo
Plus Sign+NoYesNo
Question Mark?NoYesNo
Quotation MarkNoYesNo
Semicolon:NoYesNo
Forward Slash/NoYesNo
Tilde~NoYesNo
Underscore_Yes**YesYes**
Uppercase Letters (A-Z)A-ZYesYesYes
Lowercase Letters (a-z)a-zYesYesYes
Numerals (0-9)0-9YesYesYes

In order to test for the special characters above I have created the following script


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
cls
 $array = @('~', '!', '#', '$', '%', '^', '&amp;', '(', ')', '-', '.+', '=', '}', '{', '\', '/', '|', ';', ',', ':', '&lt;', '>', '"')
 $samaccountarray = @('[', '\', '"', '|' , ',' , '/', ':', '&lt;', '>', '+', '=', ';', ']')
 foreach ($char in $array) {
 Write-Host "Please Wait... Detecting",$char," in samaccountname" -ForegroundColor Yellow
 $objects = Get-distributiongroup
 foreach ($object in $Objects)
 {
 try {
  if ($object.SamAccountName -like "*$char*")
 {
 Write-Host "Special Character",$char,"detected in SamAccountName",$object.samaccountname -ForegroundColor Red
 
 }
 else
 {
 #Write-Host "Special Character",$char," not detected in " $object.UserPrincipalName
 }
 }
 catch
 {
 Write-Host "Great News!! we was unable to detect",$char,"in samaccountnames for all Distribution List" -ForegroundColor Green
 }
 }
 }
Get-SpecialCharacters (62 downloads)

If you are interested in understanding what IDFix does and what special characters are not supported, please see this link

https://docs.microsoft.com/en-gb/office365/enterprise/prepare-for-directory-synchronization?redirectSourcePath=%252fen-us%252farticle%252fPrepare-to-provision-users-through-directory-synchronization-to-Office-365-01920974-9e6f-4331-a370-13aea4e82b3e

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