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.
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.
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
if ($ModuleCheck) {
Write-Host 'Info: Detected an installation of the',$Module.Name,'Module' -ForegroundColor Green
$Module = Get-Module -Name $Module.Name -ListAvailable
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:
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
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.
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.
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
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
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
Name
Character
User Name
Password
Email Address
Accent
`
No
Yes
No
Ampersand
&
No
Yes
No
Angle Brackets
< >
No
Yes
No
Apostrophe
’
No
Yes
Yes***
Asterisk
*
No
Yes
No
At Symbol
@
No
Yes
No
Backslash
\
No
Yes
No
Braces
[ ]
No
Yes
No
Brackets
{ }
No
Yes
No
Circumflex
^
No
Yes
No
Colon
:
No
Yes
No
Comma
,
No
Yes
No
Dollar Sign
$
No
Yes
No
Equal Sign
=
No
Yes
No
Exclamation Point
!
No
Yes
No
Hyphen
–
Yes*
Yes
Yes*
Number Sign
#
No
Yes
No
Parentheses
( )
No
Yes
No
Percent Symbol
%
No
Yes
No
Period
.
Yes*
Yes
Yes*
Pipe
|
No
Yes
No
Plus Sign
+
No
Yes
No
Question Mark
?
No
Yes
No
Quotation Mark
“
No
Yes
No
Semicolon
:
No
Yes
No
Forward Slash
/
No
Yes
No
Tilde
~
No
Yes
No
Underscore
_
Yes**
Yes
Yes**
Uppercase Letters (A-Z)
A-Z
Yes
Yes
Yes
Lowercase Letters (a-z)
a-z
Yes
Yes
Yes
Numerals (0-9)
0-9
Yes
Yes
Yes
In order to test for the special characters above I have created the following script
}
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
}
}
}
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.
