In the first two parts of this series (part 1; part 2) we covered the PowerShell CLI and the associated scripting language, and we also covered Cmdlets and discovered how they’re the fundamental building blocks of the PowerShell world. In this part we will be discussing the PowerShell ISE and what it can do for you. Introducing the .ps1 file format. In Part 2 of this series we ran 3 commands in the CLI to validate a directory path, create a non-existent directory and then pipe the output of the DIR command to a text file. We did all of this from the CLI because that’s how you manually enter commands for PowerShell to run. This is a bit clunky though. If we had to open the CLI every time we wanted to run commands in PowerShell its usefulness and indeed its real world applications would be limited at best. Much like the CMD prompt had batch scripts, PowerShell has its own scripting file format that allows us to write scripts and run them all at once or even as part of an automated procedure. Enter the .ps1 file. A .ps1 file is essentially the next step in the evolution of the .bat file. Like batch files, a .ps1 file is a plain text file that the PowerShell interpreter steps through line by line, running the individual commands sequentially and combining the output as necessary. For example, if we were to combine the three commands from the exercise in Part 2 into a .ps1 file (for the sake of this example we’ll call it ITPS_B3_Example1.ps1) we would start off with something that looks like this: Test-Path C:\Utils New-Item C:\Utils -ItemType directory dir | Out-File C:\Utils\dir.txt Running a script from windows explorer is as easy...

In part 1 of this series we were introduced to the PowerShell CLI and ran the Get-Help command. In this part we will introduce you to Cmdlets. Introducing Cmdlets Cmdlets (pronounced command-lets) are specialised commands used in the PowerShell environment to call specific functions. To put this another way, Cmdlets are simple ways of calling and executing the pre-built commands in PowerShell. PowerShell Cmdlets are easily identifiable because they use binomial nomenclature – ie there are always 2 parts to the name and both parts are separated by a hyphen. For example: The Get-Help command that we used in Part 1 is actually a Cmdlet. In part 1 of this series I mentioned that we could pipe the output of the legacy dos command DIR to a file with a single line entered into the PowerShell CLI. To do this we would enter the following text in the PowerShell CLI: dir | Out-File C:\Utils\dir.txt In plain English this says “Take the output of the dir command and give it to the Cmdlet Out-File to be written to the file dir.txt in the C:\Utils\ path. Pretty powerful stuff for a command that is only 31 characters long. You might have noticed that there is a character in that command that you might not be familiar with. It’s the | character and on most US style keyboards it’s located on the same key as the \ key. The | character is what we refer to as the pipe operator. It tells PowerShell to take the output of what comes before and hand it off to what comes next. For more information on the | operator and the fun you can have with it, take a look at the activity below. Cmdlets then are the building blocks...

Author’s Note: This is the first installment of a three-part Introduction to PowerShell tutorial. This is guide is not intended to be an exhaustive treatise on PowerShell. If that is what you’re after, search PowerShell on Amazon. This is intended to be used simply as an introduction by those who are new to Microsoft’s scripting and automation language of choice. I’m a big fan of interactivity. If you’d like to play along with and become familiar with the various parts of PowerShell environment as we cover them I strongly encourage you to do this. You may already have PowerShell installed on the machine you’re using. If you don’t, you can get it from here. Introduction Unless you’ve been living under a rock, or are just starting out with Server Administration, then chances are fairly good that you’ve at least heard of PowerShell. Introduced in 2006 and currently on version 4*, Windows PowerShell is a task automation and configuration management framework from Microsoft built on the .NET Framework. The complete PowerShell environment consists of: A CLI and associated scripting language, Cmdlets (pronounced command-lets), The ISE. First cab off the rank is the a quick and dirty introduction to the PowerShell CLI. The PowerShell CLI First a little background. If you open your start menu and type cmd in the search and press enter you’ll be presented with the classic windows command line interface or CLI. This CLI, although quite powerful within certain narrow boundaries, is extremely limited when it comes to providing a scripted management interface. You can of course run batch files and accomplish a level of automation using this command line, but it is still quite limited. Nearly a decade before PowerShell was released it became apparent to Microsoft that Windows needed a way...

It’s a common question asked of IT – “Can you give me a list of who’s in Marketing?” or “How many accounts do we actually have?” Before PowerShell, this was a lot harder to do. There were companies like Quest Software who provided several handy tools (and still do) , or long complicated visual basic scripts. So, how do you get a list of users? All of this is being done from the Active Directory Module for Windows PowerShell which will install as part of the Windows Server 2012 Feature – Role Administration Tools > AD DS and AD LDS Tools > Active Directory Module for Windows PowerShell. The ‘Get-ADUser’ command is what we’ll use to demonstrate what you can do. For starters, ‘Get-ADUser -filter*’ will get you a list of all users, and they’ll output in this format one after the other: A lot of information. You can specify a single user with: Get-ADUser -identity username which will just show you the one result. As you may be aware, there are a lot more fields a user has than just the ones shown. You can tell PowerShell to show you all the properties by modifying the command like this: Get-ADUser -identity username -properties * Note that in PowerShell v4 if you get the error “get-aduser : One or more properties are invalid.” then there may be an issue with your schema. Check out this post for more information. If there’s just one extra property you need, there’s no point getting everything, so if you needed to see a field such as “Department” for all users then adjust the command like this: Get-ADUser -filter * -properties Department Now, this gives the results for every single user in your Active Directory environment. You can narrow this down to a particular...

Lync 2010 with Enterprise Voice attaches a phone number to a user with a direct one to one relationship. This means that when a user departs, the account should get disabled along with any Lync attachments. In turn, this abandons the phone number that was attached to the user. All great by design, but what about external people that are still calling the number of the departed user? You could leave the user’s Active Directory account disabled, leave Lync attached and configure it that way, but that’s a big hassle. Microsoft covers this scenario with a feature called “Unassigned Number”. Unassigned Number lets you configure an Announcement on an entire number range. The idea is that if any extension in the number range configured (which can be a single number) is called and isn’t attached to a user, it will divert the call to either an Announcement or an Exchange UM Auto Attendant number. Generally just the Announcement is fine, because the Announcement can be configured to be nothing, but divert the call to wherever you want it to go afterwards. The Announcement needs to be configured before you create an Unassigned Number Range, which can only be managed by PowerShell. The Unassigned Number Range can be created via the Lync Control Panel GUI or PowerShell which seems a bit inconsistent. Creating an Announcement is rather easy still, with a great guide from TechNet here. The important bits are to give your Announcement a name, tell it which Lync Pool to use and give it a target SIP address to send the call to. An example command do this is: New-CsAnnouncement -Identity ApplicationServer:lyncpool.mydomain.com -Name "Forward Announcement" -TargetUri sip:reception@mydomain.com Note that if you use a direct phone number for the sip address, you need to append...

What is PowerShell?  PowerShell is a powerful tool for managing Microsoft products and operating systems; one whose importance will only grow with time.  All components in Microsoft’s Windows Server 2012 have PowerShell APIs.  All new Server products (SystemCenter, Lync, SQL, Exchange) whose development started after 2007 are to be completely PowerShell based.  The GUIs as exist within Server 2012 or any other products Microsoft produces (with the exception of endpoint operating systems) are merely GUI layers activating PowerShell scripts.  Office 365 and Azure are both addressable via PowerShell and even third party applications are by vendors deeply embedded within the Microsoft ecosystem are being coded to be PowerShell friendly.   What is the problem with PowerShell? The PowerShell ecosystem is heavily fragmented.  Even Microsoft’s own resources are heavily distributed; there is no one place that an administrator can go to research all PowerShell commands.  Each application maintains its own documentation resources.  Community resources are scattered and rang from scripts to simplification of the often nearly incomprehensibly unhelpful Microsoft documentation to third-party PowerShell modules designed to simplify tedious tasks.  (MessageOps’s PoswerShell PST Migrator is an excellent example.)   What are the consequences of this issue? This makes creating PowerShell scripts time consuming and research-prone.  It makes using PowerShell in a non-scripted fashion even worse.  It brings us back to an MS-DOS era of laminated “cheat sheets” and sacred text files filled with arcane strings of code that nobody can but “the guru” can decode, but which are nonetheless vital to the everyday workings of systems administrators. This has dark security implications.  Modules that are loaded into PowerShell are often kept in ad-hoc repositories consisting of a simple directory on a file server.  They are rarely up-to-date as no automated update mechanism exists.  Scripts sourced from...