While there is a plethora of articles written about PowerShell, Hey, Scripting Guy!, where I regularly seem to end up at while trying to figure out how to do something new/different, I’m often asked about PowerShell when I’m working with customers. You see, if you’re like me, you’ve spent most of your IT life working in a Graphical User Interface (GUI). It’s comfortable, it’s often intuitive and you can click around ’till you find what you’re looking for if you’re not entirely sure. While UNIX and Networking Admins may have been laughing at us all this time, we secretly knew that the GUI made our lives easier than theirs, as they scrolled through man pages billions of lines long. The problem now though, is there’s a bunch of stuff to do with the Office 365 platform which can only be done with PowerShell. And PowerShell is a Command Line Interface! What’s with that? Why is Microsoft making our lives as hard as the UNIX guy?
These are both very good questions in my opinion, and I should know as I just asked them. Sure reaching back into the dim dark ages there’ve been CLI tools in the Windows world since, well since Windows. Batch scripts come to mind. Which by the way I hated having to do anything with. I found batch scripting confusing and (a lot) intimidating quite frankly. I digress. There’re some day to day tasks which administrators in companies using Office 365 have to do in PowerShell, and guys like me, who’ve lived their lives in GUI land are a little bit confronted by the blue box with white writing, you can’t just click around to find stuff.
There are some things we can do and remember however, which will make our PowerShell experience easier and less of a headache. The first is the PowerShell profile, which is discussed in some detail by The Scripting Guys here, you’ll also find a lot more by banging in “PowerShell profile” into Google. I am (if I haven’t said this before) first and foremost, a lazy individual. I don’t like doing things more than once and I find typing things out tedious, yes I see the irony. As a result of my innate laziness, one of the first things I did when I was told I had to use PowerShell, was look at this profile thing.
Just a quick recap on what the Internet has taught me about PowerShell profiles:
- They exist
- Their path is stored in a variable called $profile whenever you open a shell. (something like C:\Users\Jason\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 in my case)
- They can store functions.
- You need to create the Microsoft.PowerShell_profile.ps1 file yourself.
Why is this so neat? You can store functions! Repeatable bits of code you seem to be continually typing into that blasted blue box! Think the following:
- Loading Modules and PSSnapins (think Add-PSSnapIn Microsoft.Exchange.Management.PowerShell.E2010 for those Exchange Admins out there)
- Creating a remote session into Exchange Online
- Changing federated domain names for a user’s UPN
BTW, since Windows 8 and Windows Server 2012, modules load automatically when you start to type a cmdlet from the shell (brilliance)!
Some ideas for a PowerShell profile:
[code language=”PowerShell”]
$myFunctions = "Load-Module","Connect-O365","Connect-EOL"
# $myFunctions
Function Load-MyModule ($modName)
{
if (-not(Get-Module -Name $modName))
{
if (Get-Module -ListAvailable | ?{$_.name -eq $modName})
{
Import-Module -Name $modName
Write-Host "$modName has been loaded successfully" -ForegroundColor White
}
else
{
Write-Host "It’s not going to work fella. $modName is not installed" -ForegroundColor Red
}
}
}
Function Connect-O365
{
# This seems a bit redundant. It just loads the MSOnline module first.
Load-Module "MSOnline"
Try
{
Connect-MsolService -Credential (Get-Credential)
}
Catch
{
Write-Host "Couldn’t connect to Office 365 Azure AD. Please speak to your Administrator." -ForegroundColor Red
}
}
Function Connect-EOL
{
$session = New-PSSession -ConfigurationName Microsoft.Exchange `
-ConnectionUri "https://ps.outlook.com/powershell/" `
-Credential (Get-Credential) `
-Authentication "Basic" `
–AllowRedirection
Import-PSSession $session –AllowClobber
}
[/code]
It’s not uncommon to come across scripts on the Internet using swizzle sticks, whizz bangers and a bunch of other stuff which is tricky to figure out. The thing is though, for your everyday use? It doesn’t always have to be complicated. While what you see above may seem basic and not particularly robust functions, they simplify stuff. The thing that scripts have always had over the GUI? They allow repeatable tasks to be completed over and over and over and over again without the risk of RSI. Often putting them together in the first place will take a serious amount of time (especially when starting out) but the investment is often worth it.
I hope this get you thinking about what else you may want to do with the blue box with white writing. Next time I’ll give you my take on renaming UPNs with federated domains.