If you want to see an example of a GUI application created in Windows PowerShell, take a look at the Lync Server Deleteomatic. If you want to learn how to use PowerShell to create your own Deleteomatic, or any other type of GUI application, read this article. We’ll take you through step-by-step.

 

This article is for anyone working with Windows PowerShell. If you’re not working with Lync Server, we’ve pointed out where the Lync Server specific code is and you can easily replace it with any other .NET or PowerShell code.

 

https://blogs.technet.com/b/csps/archive/2011/12/07/guiapp.aspx

 

Creating Your Own GUI Application

(Création de Votre Propre Application GUI)

 

 

This might come as a shock to many of you, but there was a time – a time long, long ago – when people didn't have cell phones. What could that even mean not to have cell phones? Well, for one thing, that meant that, if you left your house or your office, there might be a few minutes when people wouldn't be able to get hold of you! (Quelle horror!) If you had to run to the store you couldn't update your Facebook page while browsing through the produce section, and you couldn't read Ashton Kutcher's latest tweet while standing in the checkout line. You couldn't even call your wife to tell her, "I'm turning into the driveway right now." Zut alors!

 

 

Shocking? You bet. But you know what's really shocking? Here's what really shocking: back in those days, hardly anyone ever moped around lamenting the fact that no one had invented cell phones yet. Because no one had ever seen a cell phone no one really gave the idea of having a portable phone a second thought. It wasn't until people actually saw a cell phone that they suddenly realized one thing: they couldn't possibly live without one.

 

We mention this only because the same notion applies to things other than cell phones. For example, up until recently many of you might not have known that you can write GUI "applications" using Windows PowerShell; considering the fact that PowerShell is a command-line tool why would you know that? But now, having seen the Deleteomatic application created by the authors of the Lync Server PowerShell blog, you're probably thinking this: I can't possibly live without knowing how to create my own GUI application using Windows PowerShell.  Fortunately for you, the authors of the Lync Server PowerShell blog are here.

 

 

So how do you write a GUI "application" using Windows PowerShell? Good question, and one that we're going to try to answer for you. (Just don’t expect the entire answer to come in this one article.) What we thought we would do is essentially walk you through the process of building your own Deleteomatic, or at least something vaguely similar to the Deleteomatic. We won't necessarily cover everything we did when creating the Deleteomatic, and we'll definitely go off on a few tangents every now and then in order to make a point. However, by the time we finish with this series you should be fully capable of sitting down and creating your very own Deleteomatic.

 

And, if not, well, hopefully by then someone will have written an app that will allow your cell phone to create a Deleteomatic for you. Either way you should be good to go.

 

Step 1: Creating a Windows Form

 

To begin with, we should point out that there are no tricks involved here, nor do you need any special software or equipment to create the application we're going to create. In fact, all you really need is:

 

·         Windows PowerShell 2.0 (which you already have)

·         Notepad, or any other text editor (which you also already have)

·         A computer that has the Lync Server core components installed, or, at the least, a computer that can make a remote connection to a Lync Server computer and then import the Lync Server PowerShell module. Either way, you have to run the application on a computer that can run the Lync Server PowerShell cmdlets at the same time.

 

 

OK, technically you'll also need one other thing (which, again you already have): the .NET Framework. As it turns out, in order to create a GUI application using Windows PowerShell, we need to tap into the mysteries of the .NET Framework. Not that we're going to tap too deep: to be honest, we're not going to come anywhere near exploring all the different things you can do with the .NET Framework. That's more than we can cover in this series and a bit outside our area of expertise, to boot.

 

So then what will we do in this series? Things like this:

 

# Set up the form ===========================================================

 

[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")

[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Drawing")

 

$objForm = New-Object System.Windows.Forms.Form

$objForm.Text = "Microsoft Lync Server 2010 Practice Application"

$objForm.Size = New-Object System.Drawing.Size(1200,800)

$objForm.StartPosition = "CenterScreen"

$objForm.KeyPreview = $True

 

What exactly is that? Well, that's Windows PowerShell code that creates a Windows form, the window where our GUI application will reside. What you need to do (if you're playing along at home) is copy that code exactly as-is, paste it into a text editor, and then save the code as a file with a .PS1 file extension (we saved ours as C:\Scripts\Practice.ps1). In other words:

 

 

So what did we just save? Well, let's break that opening hunk of code down a bit. Ignoring the comment found in the first line of code, that hunk of code kicks off with these two lines:

 

[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")

[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Drawing")

 

These two lines of code are used to load the .NET Framework classes we need in order to build a GUI application.  Before you ask, yes, it's true: sometimes you have to explicitly load .NET classes using syntax like this, and sometimes you can use shortcuts that make the whole process a lot easier. (PowerShell is funny that way.) For example, this line of code creates a GUID using the .NET Framework, but without all that weird System.Reflection.Assembly stuff:

 

$x = [guid]::NewGuid()

 

Why do we sometimes have to use all that weird System.Reflection.Assembly stuff while other times we don't have to use it? Well, for this introductory article we aren't' going to worry about that. For now, let's just say that you need to use the two lines of code shown above in order to gain access to the System.Windows.Forms and the System.Drawing classes. As we get a little further down the road we'll delve a little deeper into .NET.

 

Probably.

 

At any rate, that brings us to this block of code:

 

$objForm = New-Object System.Windows.Forms.Form

$objForm.Text = "Microsoft Lync Server 2010 Practice Application"

$objForm.Size = New-Object System.Drawing.Size(1200,800)

$objForm.StartPosition = "CenterScreen"

 

This chunk of code is used to create and configure our window. In the first line, we use PowerShell's New-Object cmdlet to create a new instance of the System.Windows.Forms.Form class, an instance we store in an object reference named $objForm. (By the way, a lot of the things we do in order to create our GUI application will require us to create new objects that get stashed in object references.) After that we use the next few lines of code to modify property values of our new object. For example, in the second line we set the window caption (the Text property) to Microsoft Lync Server 2010 Practice Application, and in line 3, we set the size of our window: 1200 pixels wide by 800 pixels tall. Finally, we use line 4 to ensure that, when our application starts up, that application will be centered onscreen.

 

Got all that? Excellent. Now, copy that code into Notepad and save the file with a .PS1 file extension. At that point, we're ready to take this baby out for a spin. To do that, from within the Lync Server Management Shell (or from your remote instance of Windows PowerShell), type the full path to your script file and then press ENTER. For example:

 

c:\scripts\practice.ps1

 

So what happened when we ran our script? Here's what happened:

 

 

If you're thinking, "I don't get it; it doesn't look like anything happened," well, you're right: nothing did happen. Well, OK, technically the script did run, but nothing appeared on screen (let alone a GUI application). Why not? That's easy: as it turns out, simply creating a form isn't good enough. Instead, you actually have to activate the form and then explicitly tell PowerShell to display that form. If you don't, you'll get exactly what we got: nothing (rien).

 

Fortunately, activating and displaying a form doesn't take much effort. All you have to do is copy these lines of code and paste them at the very bottom of your script:

 

# Activate the form =========================================================

 

$objForm.Add_Shown({$objForm.Activate()})

[void] $objForm.ShowDialog()

 

Incidentally, when we say "the very bottom" we mean "the very bottom." (We apologize for this, but the best we can translate "the very bottom" as is "au fond," or, "at the bottom." Sorry.) These lines of code need to be the last lines in your script. That's important to keep in mind, because we're going to be adding a bunch of additional code to this script; when we do that, we have to make sure that all the code we add comes after our initial block of code (the code that creates the Windows form) but before the code that activates the form.

 

So what happens now if we run our script? This happens:

 

 

Voilá: we have a GUI application!

 

OK, sure, it might not be a great GUI application; after all, it doesn't really do much except show up on screen. (Although you could make an argument that software that doesn't do anything is sometimes preferable to what "real" pieces of software occasionally do.) But your point is well taken: who wants to spend their day laboring over stuff that doesn't do anything and that nobody even cares about?

 

Present company excepted, of course.

 

So let's see if we can get our application to actually do something. For starters, let's add a listbox to our application. Copy the following lines of code into your script, taking care to place these lines after the initial code block but before the code that activates and displays the form:

 

# Add the listbox containing the Get-Cs cmdlets =============================

 

$objCmdletsListbox = New-Object System.Windows.Forms.Listbox

$objCmdletsListbox.Location = New-Object System.Drawing.Size(50,40)

$objCmdletsListbox.Size = New-Object System.Drawing.Size(260,320)

 

$objForm.Controls.Add($objCmdletsListbox)

 

If you take a moment to glance at this code, it should be fairly obvious that the code is adding a new listbox to the form. (If nothing else, the comment, which starts off “Add the listbox,” should have given it away.) In line 1, we use the New-Object cmdlet to create a new instance of the System.Windows.Forms.Listbox class, storing this new instance in the variable $objCmdletsListbox. In line 2 we set the location for our listbox: 50 pixels from the left-hand side of our window and 40 pixels from the top of our window. In line 3, we configure the size of the listbox: 260 pixels wide by 320 pixels tall.

 

 

By the way, don't forget to include the last line of code, the one that actually adds the listbox to the Controls collection for the form. What would we get if we forgot to add that line of code? Beats us. But one thing that we definitely wouldn't get is a listbox.

 

So what's our application look like now? Well, assuming that we closed the original version of the application, modified our script, saved that modified script, and then restarted the application, we should now have something that looks like this:

 

 

That's what we said: wow.

 

 

We see that, once again, you're not quite as impressed as we are. Granted, our application now has a listbox, but there's nothing in that listbox. And you're right: a listbox without data is like a day without sunshine.

 

Or pretty much like any day here in the Seattle area. (Currently 40 degrees and drizzling.)

 

OK, fine. If you aren't impressed yet then let's see if we can add a little zing to our listbox. Let's try this: let's see if we can retrieve all the Lync Server Get-Cs cmdlets (Get-CsAddressBookConfiguration, Get-CsExternalAccessPolicy, Get-CsServerApplication, etc.) and then add those add those cmdlets to the listbox. Do we really think we can do that? Oui!

 

 

Here's what we're going to do: we're going to copy the following block of code and then paste that code immediately after the lines of code that created the listbox. Here's the block of code we're talking about:

 

$items = Invoke-Expression "Get-Command Get-Cs*"

 

foreach ($item in $items)

  {   

      [void] $objCmdletsListbox.Items.Add($item.Name)

  }

 

Right now you're probably thinking, "Quelle est cette?" (What is this?) We'll tell you what this is: this is code that retrieves all the Get-Cs cmdlets and then adds those cmdlets to our listbox. Quelle horror!

 

Oh, wait; sorry. Quelle horror means "how horrible!" We should have said something like this: tres bien! (Very good!)

 

So how does this code do that? Well, to begin with, it uses the following command to retrieve all the Get-Cs cmdlets and stash the returned data in a variable named $items:

 

$items = Invoke-Expression "Get-Command Get-Cs*"

 

Incidentally, that line of code gives us a chance to make an important point about working with GUI applications. As you know, if we were in the PowerShell console itself we could retrieve all the Get-Cs cmdlets (and store the returned data in a variable) by using a command like this one:

 

$items = Get-Command Get-Cs*

 

But remember, we aren't in the PowerShell console: we're in our cool, new GUI application. Because of that, we can't call PowerShell commands like this one directly; instead, we need to pass those commands as strings and let Invoke-Expression call those commands. Why? Well, because – well, again, for now we aren't going to worry about the why part of this. Instead, it's just important to know that we have to take this approach whenever we call a PowerShell command: put the command into a string, then run the command (the string) using Invoke-Expression. For now, just trust us on that one.

 

As difficult as that is to do.

 

So now that we have all the Get-Cs cmdlets safely stashed away in the variable $items what do we do with these cmdlets? That's what these lines of code are for:

 

foreach ($item in $items)

  {   

      [void] $objCmdletsListbox.Items.Add($item.Name)

  }

 

What we've done here is set up a foreach loop that loops through each cmdlet stored in the variable $items. And what do we do each time through the loop? Well, each time through the loop we use this line of code to add the cmdlet Name to our listbox:

 

[void] $objCmdletsListbox.Items.Add($item.Name)

 

See how that works? A listbox has an Items property, the Items property has a method named Add. All we have to do is tell the Add method what we want to add: in this case, that's the cmdlet Name. What if we didn't want to put cmdlet Names in our listbox but, instead, we wanted to put French color names in that box? In that case, we'd just use a series of commands similar to these:

 

[void] $objCmdletsListbox.Items.Add("blanc")

[void] $objCmdletsListbox.Items.Add("noir")

[void] $objCmdletsListbox.Items.Add("rouge")

[void] $objCmdletsListbox.Items.Add("vert")

 

Etc., etc.

 

 

So, once again, let's close our application, modify our code, save the changes, and then re-run the script. Puis? (And then)? Et puis cette: (And then this):

 

 

Not bad, eh? (Pas mal, eh?) Granted, you might not be terribly impressed, but take a minute to think about what we've done here. Using nothing fancier than Notepad and a few PowerShell commands, we've created an application that pops up in a real, live window. As if that wasn't cool enough, we've added a standard Windows user interface control to that window (the listbox) and then, by calling out to Windows PowerShell and running a Lync Server PowerShell cmdlet, we've managed to populate that listbox with real, live data. All things considered, that's definitely not bad, not bad at all.

 

But we've hardly begun to scratch the surface of what we can do here. For example, let's see if we can turn this up a notch and maybe get our little application to do something semi-useful. (Something our managers have been trying to do with us for several years now.) Here's what we're going to do: we're going to add a second listbox to our application! (That's right: zut alors!) Copy this code and paste it after the code we used to populate our first listbox:

 

# Add the Instances listbox  ================================================

 

$objInstancesListbox = New-Object System.Windows.Forms.Listbox

$objInstancesListbox.Location = New-Object System.Drawing.Size(50,400)

$objInstancesListbox.Size = New-Object System.Drawing.Size(260,200)

$objForm.Controls.Add($objInstancesListbox)

 

Because you're now an old hand at creating listboxes we won't bother explaining what this block of code does. Instead, let's just save the script and re-run it. When we do that, our application should look something like this:

 

 

Just like we said: two listboxes in a single application!

 

Again, that's pretty cool in and of itself. But you know what would be even cooler? That's right: what would be even cooler is if we could populate this second listbox with some data, too. Fortunately enough, we just happened to have some code that does that very thing:

 

# Add the subroutine for retrieving instances ===============================

 

$objCmdletsListbox.Add_Click(

  {

    $cmdlet = $objCmdletsListbox.SelectedItem

    $items = Invoke-Expression "$cmdlet | Select-Object Identity"

    $objInstancesListbox.Items.Clear()

       

      if ($items –ne $Null)

      {

        foreach ($item in $items)

        {  

            [void] $objInstancesListbox.Items.Add($item.Identity)

         }

      }

    })

 

So is this just your plain old, every day, fill-a-listbox-with-data code? Hardly. What we have here is a subroutine that specifies the actions that should take place when someone clicks on our first listbox. How do we know that this subroutine specifies the actions that should take place when someone clicks on our first listbox? Well, as you might recall, when we created that first listbox we also created an object reference named $objCmdletsListbox. As you can see, we're using that object reference when defining our subroutine; in fact, what we're doing is adding the Click method (Add_Click) to the listbox referenced by $objCmdletsListbox. What's the point of that? Here's the point of that: this method tells our application what to do any time someone clicks in the listbox containing our list of cmdlets.

 

 

And just what is our application going to do when someone clicks in that listbox? The first thing it's going to do is figure out which item in the listbox was actually clicked; that's what this line of code (and the SelectedItem property) is for:

 

$cmdlet = $objCmdletsListbox.SelectedItem

 

As you know, our listbox is filled with cmdlet names. That means that $cmdlet will contain a cmdlet name. For example, if we clicked on Get-CsExternalAccessPolicy then $cmdlet will be equal to Get-CsExternalAccessPolicy. If we click on Get-CsAdDomain then cmdlet will be equal to Get-CsAdDomain. If we – well, you get the idea.

 

So does any of that really matter to us? Well, it will in a moment. Take a look at the next line of code:

 

$items = Invoke-Expression "$cmdlet | Select-Object Identity"

 

What we've done here is constructed another Lync Server PowerShell command and then used Invoke-Expression to call that command. If $cmdlet is equal to Get-CsExternalAccessPolicy then that means we've constructed, and then executed, this command:

 

$items = Get-CsExternalAccessPolicy | Select-Object Identity

 

In other words, we clicked on Get-CsExternalAccessPolicy and, in response, our application has just run that very same cmdlet (Get-CsExternalAccessPolicy), returned the Identity of each our external access policies, and then stashed those Identities in the variable $items.

 

And yes, that is kind of nifty, isn't it?

 

But the next part is even niftier. What we're going to do next is take those policy Identities and display them in our second listbox; in other words, when you click a cmdlet in the first listbox, all the instances returned by that cmdlet are displayed in the second listbox. (You'll see a visual explanation of that in just a second.)

 

Before we do that, however, we need to clear any existing items out of listbox No. 2; that's what this line of code is for:

 

$objInstancesListbox.Items.Clear()

 

And then we use this foreach loop to methodically add each policy Identity to the listbox:

 

    if ($items –ne $Null)

    {

      foreach ($item in $items)

      {  

            [void] $objInstancesListbox.Items.Add($item.Identity)

       }

 

 

So what does all that give us? Well, after we save and restart the script, and if we then click on Get-CsExternalAccessPolicy, we should now see something like this:

 

 

As you can see, in our little test deployment of Lync Server we have two external access policies: Global, and Tag:RedmondExternalAccess. See, we told you this would be cool, didn't we?

 

But before we get too carried away with congratulating ourselves, and before our arms get too tired from patting ourselves on the back, let's issue one caveat. (Which kind of sounds like a French word, but actually comes from the Latin word cavere, or "let him beware.") Our application is going to work just fine for most of the Get-Cs cmdlets. How do we know that? We know that because most of the Get-Cs cmdlets will work without you specifying a particular item to be retrieved. For example, do you want information on all your external access policies? Then run this command in the Lync Server Management Shell:

 

Get-CsExternalAccessPolicy

 

What about information for all your analog devices? The run this command:

 

Get-CsAnalogDevice

 

However, (and, unfortunately), there are some exceptions. For example, try running this command:

 

Get-CsRgsConfiguration

 

Is that going to return all your Response Group configuration settings? Sadly, no, it's not. Instead, it's going to prompt you for the Identity of the settings to be returned:

 

cmdlet Get-CsRgsConfiguration at command pipeline position 1

Supply values for the following parameters:

Identity:

 

Is that a problem? Well, not if you're working in the PowerShell console; you just answer the prompt and get on with your life. But if you're working in our little application, yes, it is a problem. This prompt isn't going to appear in the application, it's going to appear in the PowerShell console. Even worse, your application is going to get all hung up, because it can't run Get-CsRgsConfiguration until it knows which Identity to use.

 

Now, there are things we can do to guard against this problem, but in this initial article we aren't going to worry about those things; instead, we're just going to warn you not to click on cmdlets like Get-CsRgsConfiguration. You should also avoid clicking these cmdlets:

 

·         Get-CsAdContact

·         Get-CsAdminRoleAssignment

·         Get-CsAdUser

·         Get-CsClientCertificate

·         Get-CsClientPinInfo

·         Get-CsUICulture

·         Get-CsUser

·         Get-CsUserAcp

·         Get-CsUserPoolInfo

 

 

So what happens if you ignore all our warnings (as if people were going to suddenly start taking our advice) and click Get-CsRgsConfiguration anyway? Well, in that case, we recommend that you go back to the PowerShell console and press Ctrl+C to kill the current command. (You might have to do that several times to finally kill the command.) When Ctrl+C finally takes effect you should then see an error message similar to this one:

 

 

Click the Continue button to dismiss the error message, then close and restart your GUI application. That should take care of the problem. If it doesn't, you'll probably have to terminate and restart PowerShell. It's kind of a hassle but, hey, this is version 1 of our application. And since when has version 1 of any product from Microsoft ever worked?

 

 

Originally that was all we were going to do for this first article. When we got this far, however, we realize that we didn't want to end on such a gloomy note, what with all this talk of killing commands and unhandled exceptions. With that in mind, let's jazz this thing just a little more. First, let's toss in some code that adds a text box to our form:

 

# Add a text box to the form  ===============================================

 

$objOutputBox = New-Object System.Windows.Forms.TextBox

$objOutputBox.Location = New-Object System.Drawing.Size(680,40)

$objOutputBox.Size = New-Object System.Drawing.Size(460,500)

$objOutputBox.Multiline = $True

$objOutputBox.Font = New-Object System.Drawing.Font("Courier New", "8.5")

$objOutputBox.Wordwrap = $True

$objOutputBox.ReadOnly = $True

$objOutputBox.ScrollBars = [System.Windows.Forms.ScrollBars]::Vertical

$objForm.Controls.Add($objOutputBox)

 

That's going to give us a form that looks like this:

 

 

 

Our next step – as you might have guessed – is to now try and display some data in that brand-new textbox. What we've decided to do is this: when you click an item in our second listbox (the one that displays things like our external access policies) we want all the properties of the clicked item (for example, the Global external access policy) to appear in the textbox. Are we even capable of pulling off such a feat? Probably not. But that's never stopped us before:

 

# Add the subroutine for retrieving instance values =========================

 

$objInstancesListbox.Add_Click( 

  {

    $cmdlet = $objCmdletsListbox.SelectedItem

    $instance = $objInstancesListbox.SelectedItem

    $objOutputBox.Text = Invoke-Expression `

      "($Cmdlet -Identity $instance | Format-List | Out-String).Trim()"

  })

 

What we've done here is add a subroutine to the instances listbox ($objInstancesListbox); this subroutine is going to tell our application what to do if someone clicks a specific instance of a policy or configuration setting. And what is our application going to do? Well, first it's going to grab the cmdlet name from the first (cmdlets) listbox; that way, it knows which cmdlet it needs to use:

 

$cmdlet = $objCmdletsListbox.SelectedItem

 

Next, it's going to grab the Identity from the second (instances) listbox:

 

$instance = $objInstancesListbox.SelectedItem

 

And once the application knows both the cmdlet name and the instance Identity it can then construct a command, run that command, and write the output to the textbox:

 

$objOutputBox.Text = Invoke-Expression `

  "($Cmdlet -Identity $instance | Format-List | Out-String).Trim()"

 

That's kind of a complicated-looking command, so let's explain just exactly what it's doing, and why it's doing that. The first part is actually pretty easy: it's just using the selected Get-Cs cmdlet to return the selected instance:

 

$Cmdlet -Identity $instance

We next take the data that comes back and pipe it to the Format-List cmdlet; Format-List will then display the data as a list rather than a table. Does that matter? In some cases, no: typically the data will be displayed as a list anyway. However, that might not be the case when we start to add even more bells and whistles to this application; when we do that, PowerShell might try to display some of our data as a table. Because we have limited space within our text box we don't really want data displayed as a table. If we pipe everything to Format-List we don't have to worry about that.

 

If we look at our entire command it looks like this:

 

($Cmdlet -Identity $instance | Format-List | Out-String).Trim()

 

Why do we return the data, format it as a list, and then pipe it to the Out-String cmdlet? That's easy: if you grab PowerShell data from within an application like this and then try to display that data as-is in a textbox this is what you get:

 

Microsoft.PowerShell.Commands.Internal.Format.FormatStartData Microsoft.PowerShell.Commands.Internal.Format.GroupStartData Microsoft.PowerShell.Commands.Internal.Format.FormatEntryData Microsoft.PowerShell.Commands.Internal.Format.GroupEndData Microsoft.PowerShell.Commands.Internal.Format.FormatEndData

 

Cute, but not all that useful.  The only way to work around that problem (or at least the only way that we know of) is to pipe the data to the Out-String cmdlet, which converts that weird object information to string values. And then, just to make the output a little nicer-looking, we use the Trim() method to delete any blank lines or blank spaces that might appear at the beginning or the end of that output.

 

So what's the net result of all that work? This:

 

 

Pretty slick, huh? Jolie … slick ….

 

OK, that is all we're going to do today. But don't worry: we'll back soon with the next installment in the series. What will we cover in that installment? Well, we're not really sure at the moment: to tell you the truth, our articles typically come as more of a surprise to us than they probably do to you.  But you can bet (pretty much, anyway) that we'll show you how to make our GUI application even better, and even fancier.

 

Until then, all we can say is this: à bientôt! (See you later!)

 

 

 

Oh, there is one last thing: here's the complete code for all the work we did today, just in case you have any questions about what was supposed to go where. Enjoy!

 

# Set up the form ===========================================================

 

[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")

[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Drawing")

 

$objForm = New-Object System.Windows.Forms.Form

$objForm.Text = "Microsoft Lync Server 2010 Practice Application"

$objForm.Size = New-Object System.Drawing.Size(1200,800)

$objForm.StartPosition = "CenterScreen"

 

 

# Add the listbox containing the Get-Cs cmdlets =============================

 

$objCmdletsListbox = New-Object System.Windows.Forms.Listbox

$objCmdletsListbox.Location = New-Object System.Drawing.Size(50,40)

$objCmdletsListbox.Size = New-Object System.Drawing.Size(260,320)

 

$items = Invoke-Expression "Get-Command Get-Cs*"

 

foreach ($item in $items)

  {   

    [void] $objCmdletsListbox.Items.Add($item.Name)

  }

 

$objForm.Controls.Add($objCmdletsListbox)

 

 

# Add the Instances listbox  ================================================

 

$objInstancesListbox = New-Object System.Windows.Forms.Listbox

$objInstancesListbox.Location = New-Object System.Drawing.Size(50,400)

$objInstancesListbox.Size = New-Object System.Drawing.Size(260,200)

$objForm.Controls.Add($objInstancesListbox)

 

 

# Add the subroutine for retrieving instances ===============================

 

 

$objCmdletsListbox.add_Click(

  {

    $cmdlet = $objCmdletsListbox.SelectedItem

    $items = Invoke-Expression "$cmdlet | Select-Object Identity"

    $objInstancesListbox.Items.Clear()

       

      if ($items –ne $Null)

      {

        foreach ($item in $items)

        {  

            [void] $objInstancesListbox.Items.Add($item.Identity)

         }

      }

    })

 

 

# Add a text box to the form  ===============================================

 

$objOutputBox = New-Object System.Windows.Forms.TextBox

$objOutputBox.Location = New-Object System.Drawing.Size(680,40)

$objOutputBox.Size = New-Object System.Drawing.Size(460,500)

$objOutputBox.Multiline = $True

$objOutputBox.Font = New-Object System.Drawing.Font("Courier New", "8.5")

$objOutputBox.Wordwrap = $True

$objOutputBox.ReadOnly = $True

$objOutputBox.ScrollBars = [System.Windows.Forms.ScrollBars]::Vertical

$objForm.Controls.Add($objOutputBox)

 

 

# Add the subroutine for retrieving instance values =========================

 

 

$objInstancesListbox.Add_Click( 

  {

    $cmdlet = $objCmdletsListbox.SelectedItem

    $instance = $objInstancesListbox.SelectedItem

    $objOutputBox.Text = Invoke-Expression `

      "($Cmdlet -Identity $instance | Format-List | Out-String).Trim()"

  })

 

 

# Activate the form =========================================================

 

$objForm.Add_Shown({$objForm.Activate()})

[void] $objForm.ShowDialog()

 

 

 

 

 

 

 

 

 

It slices, it dices, it purees, it…well, no, it doesn’t actually do any of those things. What it does is delete, and what it is is the Lync Server Deleteomatic. We’ve create a graphical user interface with PowerShell that you can use to delete objects, such as policies and configuration settings, from Lync Server.

 

This is a handy little utility, but make sure you read the disclaimer. This isn’t a fully-tested and fully-supported (or even partially-supported) utility. All it really is is a demonstration of creating a GUI interface for your Lync Server PowerShell commands. Take a look, play around with it, send us your feedback if you have any. In this article we explain what the Deleteomatic does. In future articles we’ll explain how the Deleteomatic does what it does.

 

https://blogs.technet.com/b/csps/archive/2011/11/30/lyncdeleteomatic.aspx

 

 

 

 

Have Fun and Delete Things, Too:

The All-New Lync Server Deleteomatic

 

 

Between the Lync Server Management Shell, the Lync Server Control Panel, and all the assorted Lync Server Resource Kit tools you're probably thinking, "You know, I already have all the Lync Server management tools I could ever need." But guess what? If you are thinking that you already have the Lync Server management tools you could ever need that can mean only one thing: you haven't heard about the Deleteomatic yet.

 

 

The Whatomatic?

 

The Deleteomatic. The Deleteomatic is a little PowerShell script (well, OK, not that little; it does have more than 600 lines) that's designed to delete things. (Hence the clever name.) More specifically, the Deleteomatic is designed to delete Lync Server things, things like client policies, dial plans, Address Book configuration settings, Response Group queues, and – well, you get the idea. With one or two exceptions, if it can be deleted from Lync Server then the Deleteomatic can delete it.

 

 

Ah, that's a good question: can't you just use the Lync Server Management Shell and/or the Lync Server Control Panel to delete things from Lync Server? Of course you can; for that matter, there are probably all sorts of other tools that you can use to delete things from Lync Server. However, as incredibly useful as the Management Shell and the Control Panel are, the truth of matter is that both of these tools do have a few limitations. (For one thing, just try making julienne fries with the Control Panel and you'll soon see what we mean.) In addition to that:

 

·         Not everything that can be deleted from Lync Server can be deleted by using the Control Panel; for example, Address Book settings can't be found anywhere in the Control Panel. Admittedly, you can pretty much delete everything that's deletable by using the Management Shell; if you couldn't, the Deleteomatic (which relies on Lync Server PowerShell) wouldn't work. At the same time, however, using the Management Shell sometimes requires you to deal with … interesting … commands like this one:

Remove-CsRgsAgentGroup -Identity service:ApplicationServer:atl-cs-001.litwareinc.com/1987d3c2-4544-489d-bbe3-59f79f530a83

And yes, there are ways to work around the need to use Identities like the one shown above. But even then, typing commands from the Management Shell prompt will always require you to, well, type commands at the Management Shell prompt. And typing things is often-times easier said than dnoe.

Er, done.

·         The Control Panel only allows you to delete one item at a time. Again, you can delete multiple items using the Management Shell, but even then you can only do that if those items fit a well-defined pattern. (For example, all the client policies configured at the per-user scope.) But supposed you wanted to delete the DublinClientPolicy, the RedmondClientPolicy, and the site:Redmond policies, and delete them all in one fell swoop? Can you do that with the Management Shell? No, you cannot.

Well, OK, so maybe you can. But it's not especially intuitive how you would go about doing it.

And no, we're not going to give you a hint on how you would do that; if we did, you wouldn't need the Deleteomatic, now would you? But here's a hint on how you can do that:

"DublinClientPolicy","RedmondClientPolicy","site:Redmond" | Remove-CsClientPolicy

That works. But, again, it is a lot of typign.

Er, typing.

·         One of the golden rules of Lync Server management is this: it's never a good idea to delete a per-user policy without first unassigning that policy from any users who have been assigned that policy in the first place. Can you do that using either the Management Shell or the Control Panel? You bet you can. However, you're on your own to figure out how to unassign and then remove that per-user policy.

And this time we mean it. (OK, fine: later in this article we'll show you code that does that.)

·         Neither the Management Shell nor the Control Panel provides an obvious way to back something up before it gets deleted. As a general rule, that doesn't matter: after all, if you're planning on deleting something that's usually because you don't want the thing anymore anyway. And yet, still, there is that whole notion of being better safe than sorry. In other words, there might be times when it would be a good idea to make a backup copy of your Address Book configuration settings before you delete those settings. However, with no Backup command in the Control Panel, and with no Backup-CsAddressBookConfiguration cmdlet, well, that, too is much easier said than done.

 

Fortunately, though, the Deleteomatic has been designed to address all these issues, and more. For example, with the Deleteomatic you can delete multiple items at once, and without having to know the item's Identity. (Instead, the Deleteomatic will show you the Identity; you don't have to have all your Identities memorized.) If you choose to delete a per-user policy then the Deleteomatic will automatically unassign that policy before deleting it. And, if you want to, you can even ask the Deleteomatic to make a backup copy of something before that something gets deleted. Needless to say, it's the greatest Lync Server tool ever!

 

Official Disclaimer

 

Having said that, you should not consider the Deleteomatic to be the greatest Lync Server tool ever; in fact, you shouldn't even consider the Deleteomatic to be a Lync Server tool, period. The Deleteomatic came about because we wanted to show people how to write GUI "applications" using Windows PowerShell. (If we haven’t made it clear yet, the Deleteomatic is written entirely in Windows PowerShell.) When we first came up the idea of showing people how to add GUI elements to their scripts, we thought we'd just demonstrate how you could do something simple like, say, display a window that shows a list of all your client policies or something. However, that seemed a bit lame.

 

Yes, even for us.

 

Because of that, we started adding features to our sample script and, before we knew it, we had a Deleteomatic on our hands. (Very similar to the process Michelangelo underwent when he just started painting over a couple marks on a wall and then somehow ended up with the ceiling of the Sistine Chapel.) All of these additional features are nice, and they make the Deleteomatic look like a real application. Keep in mind, however, that the Deleteomatic is, at heart, just a demonstration of how you can write GUI "applications" using Windows PowerShell. The Deleteomatic is intended to show you the kinds of things that you can do using Windows PowerShell and the Lync Serve cmdlets. As such, it's not a real Microsoft application, it's not a supported utility, it's largely untested, it will never be localized into other languages, and we can't say with 100% certainty that, if you use the Deleteomatic, all your hair won't immediately fall out.

 

Which might explain why one of authors of the Deleteomatic always wears a baseball hat. Hey, you never know, right?

 

 

But enough about that. Let's see if we can figure out what the Deleteomatic does and how it actually does it.

 

 

 

So Where Can I Buy One of These Deleteomatics?

 

Well, you can't: the Deleteomatic is not for sale. However, what you can do is get a free copy of the thing instead: all you need to do is grab a copy of the ZIP file Deletomatic.zip (located at the end of this article) and then extract Deleteomatic.ps1 to a folder of your choice (for example, C:\Scripts).

 

Got that? Perfect. Next, start up the Lync Server Management Shell. (Or, if you prefer, start a remote session of Windows PowerShell and import the Lync Server module.) As soon as the Management Shell is up and running, type the full path to your script file and then press ENTER. In our case, that would mean typing the following at the PowerShell prompt:

 

C:\Scripts\Deleteomatic.ps1

 

With any luck, the Deleteomatic will soon appear in all its glory:

 

 

And you're right: that doesn't look like much, does it? But just wait until you see it in action.

 

 

The Deleteomatic in Action

 

To begin with, take a peek at the upper left-hand portion of the screen. What you'll see there is a list of all the Remove-Cs cmdlets:

 

 

 

So what are you supposed to do with that list of Remove-Cs cmdlets? We'd suggest you do this: click on a cmdlet of interest. For example, click on the Remove-CsConferencingPolicy cmdlet:

 

 

When you do that, two things are going happen. (Three, if you count the feeling of peace and tranquility that will likely sweep over your body.) First, you should see a brief description of the cmdlet and what it does:

 

 

More important, you should also see a list of all your existing conferencing policies:

 

 

Why is this list of existing policies important? That's easy. Thanks to this list, the Deleteomatic can now do what it was born to do: delete things.

 

 

So did you click on the Remove-CsConferencingPolicy cmdlet like we suggested? Excellent. Now, go ahead and click one of your existing conferencing policies; when you do that, the Deleteomatic should light up like a Christmas tree:

 

 

 

So what exactly is all this information that has suddenly festooned the Deleteomatic? Well, on the right-hand side of the screen you'll see all the property values for the selected policy:

 

 

Why does the Deleteomatic show you all the property values for the selected item? You got it: because that way you'll know exactly what it is you're deleting before you actually delete it.

 

We thought that was kind of handy, too. And guess what? One of the cool things about the Deleteomatic is that it lets you select (and then, if you want to, to delete) multiple items. For example, suppose you click one conferencing policy, then hold down the Ctrl key and click a second conferencing policy. That means the selected instances will look like this:

 

 

On top of that, property values for both of the selected policies will show up in the Property Values box:

 

 

Could there be anything better than that? No. That's as good as life will ever get.

 

Sorry to have to be the ones to break that to you.

 

We're the first to admit that working with multiple items is pretty exciting; for now, though, let's go back to our original scenario, the one where we selected only a single conferencing policy (TestPolicy). When we do that, we should also see the following code in the Script Code box:

 

 

What's that code for? As it turns out, that's the code that deletes the selected policy.

 

And yes, we know what you're thinking: that does look like a lot of code just to delete one little conferencing policy, doesn't it? Because of that, let's take a moment to explain why there's so much code there.

 

For starters, we have this little block of PowerShell coding:

 

Get-CsUser -Filter {ConferencingPolicy -eq "Tag:TestPolicy"} |  Grant-CsConferencingPolicy -PolicyName $Null

 

What this code does is unassign the selected policy (TestPolicy) from any users who have been assigned the policy (and it does this before the policy is deleted). What's the point of that? Well, as you probably know, if you try to delete a per-user policy and that policy is currently assigned to one or more users, you're going to be presented with a confirmation prompt similar to this:

 

The policy "TestPolicy" is currently assigned to one or more users. Assign a different policy to the users before removing this one.

The policy is in use.

[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"):

 

If you answer yes (Y), you can go ahead and remove the policy without first unassigning it from the affected users; Lync Server has no problem with you doing that. However, from that point on any time you do anything that involves user accounts and Lync Server PowerShell (even a simple thing, like listing the display names of all your users) you'll get annoying little warnings like this in your output:

 

DisplayName

-----------

Pilar Ackerman

Patrick Hines

WARNING: "TestPolicy" with identity "14" assigned to "sip:kenmyer@litwareinc.com" has been removed from configuration store.

Ken Myer

Ann Reagan

 

These warnings aren't fatal, and they don't cause any real problems. But they can be annoying.

 

 

At any rate, code like the following unassigns a per-user policy before the Deleteomatic actually deletes that policy:

 

Get-CsUser -Filter {ConferencingPolicy -eq "Tag:TestPolicy"} |  Grant-CsConferencingPolicy -PolicyName $Null

 

We should also note that you'll see a block of code like that only when you're dealing with a per-user policy; if you're dealing with a global, site, or service policy, or if you're dealing with a collection of configuration settings you won't see that code:

 

 

 

Why don't you see code for unassigning the policy? We know why: because those other items (like a global policy or like configuration settings) are never directly assigned to users. You don't have to worry about unassigning something that was never assigned to begin with.

 

 

So does all that make sense? Let's hope so, because now we're moving on to our next chunk of code:

 

Remove-CsConferencingPolicy -Identity "Tag:TestPolicy" -Confirm:$False -ErrorVariable Err -ErrorAction SilentlyContinue

 

Believe it or not, that's the code that actually deletes the TestPolicy policy. Again, you're probably wondering, "Why is there so much code?" After all, wouldn't this little bit of code work equally well:

 

Remove-CsConferencingPolicy -Identity "Tag:TestPolicy"

 

In this case, yes, that little snippet of code would work equally well. However, some of the Remove-Cs cmdlets prompt you before you actually delete something. That's fine, except that this prompt appears in the Management Shell window instead of in the Deleteomatic. There are probably all sorts of ways that we could try to trap that prompt and display in the Deleteomatic window instead. To be honest, though, that was too much trouble; we wanted to keep the Deleteomatic as simple as we could. (And we didn’t want to put too much work into the thing considering the fact that this was just a little side project and has nothing at all to do with our real work.) Therefore, we took the easy way out and added this bit of code to each command in order to suppress the confirmation prompt:

 

-Confirm:$False

 

Admittedly, you don't always need to do this: most of the Remove-Cs cmdlets don't have a confirmation prompt anyway. But, again, it was easier to just tack this on to every command rather than sit down and try to figure out which commands actually needed it and which ones didn't.

 

Then there's little addition to each command:

 

-ErrorVariable Err -ErrorAction SilentlyContinue

 

This code is there on the off-chance that something goes wrong when you try to delete an item. For example, suppose you try to delete a policy and, for some reason (maybe another administrator has just deleted it), that policy can't be deleted. Without the preceding code, the error message received would appear in the Management Shell window; that means you might never see the message. All we're doing here is capturing the error message so it can be displayed in the Deleteomatic; that's what the ErrorVariable parameter is for. Meanwhile, the ErrorAction parameter tells PowerShell to keep chugging away even if an error does occur. In turn, that means the Deleteomatic will not get hung up if, say, a particular policy can't be deleted.

 

OK. Let's assume that we will really do want to delete the TestPolicy conferencing policy. How do we do that? By clicking the Run Script button, of course:

 

 

 

Do that and the Deleteomatic will run all the code in the Script Code box. In the example we've been using, that means the Deleteomatic will unassign TestPolicy from any users who were previously assigned that policy and then remove TestPolicy from the system.

 

Just that easy, just that quick.

 

Two notes about the Run Script button. First, why do we even have a Run Script button; couldn't we just delete an item the moment you clicked on that item in the Available Instances box? Yes, we could. But that would mean that you could only delete items one-by-one. It would also mean that you could never make a mistake; after all, if you accidentally clicked on the wrong policy the Deleteomatic would go ahead and delete that policy. Based on our own personal experience, we decided it was best not to assume that a mistake would never be made.

 

Second, yes, you can modify the code in the Run Script box, and the Deleteomatic will dutifully run whatever code appears in there. We're not sure that's a great idea: for one thing, it sort of defeats the whole purpose of the Deleteomatic. For another, we can't guarantee what will happen if you type something really crazy into the Run Script box. But suppose you type this in the box and then click Run Script:

 

Get-CsDialPlan

 

In turn, information about your dial plans will be displayed in the Deleteomatic:

 

 

Kind of a weird thing to do, yes. But it works.

 

Just a few more notes and then we'll call it a day. Some of you might have noticed the Save Code and the Save Output buttons in the Deleteomatic user interface:

 

 

 

The Save Code button does exactly what the name suggests: it saves the current code to the default folder. (That's the path listed in the text box labeled Save Output and Script Code to This Folder.) Want to turn the code generated by the Deleteomatic into a regular old .ps1 script file? Then just click the Save Code button.

 

As for Save Output, clicking that button simply saves the data displayed in the Property Values box. So, yes, if you wanted to you could use the Deleteomatic to retrieve information and then save that information to a text file. Click a cmdlet, click an instance (or instances), and then, instead of deleting those instances, click Save Output to save the information.

 

Consider that another little bonus that we threw in, just for the heck of it.

 

And then there's this:

 

 

What's the Backup before deleting checkbox for? Well, to begin with, if you select this checkbox you'll end up with another little hunk of code in the Script Code box:

 

 

In other words:

 

Get-CsConferencingPolicy -Identity "Tag:TestPolicy" | Export-Clixml -Path "C:\Scripts\Lyncomatic\CsConferencingPolicy_Tag-TestPolicy.xml"

 

What this command does is make a copy of the selected item (or items) in XML format; in turn, that gives you a sort of backup copy of the selected item. And that gives you a way to restore the item should you later regret deleting it.

 

 

Finally, we should point out that the Deleteomatic is actually a fairly dynamic little application. For example, suppose we select the conferencing policy TestPolicy and then click Run Script. As soon as the policy has been removed, the Deleteomatic will automatically update the Available Instances listbox:

 

 

What more could you ask for?

 

Oh. Well, that would be a nice addition, wouldn't it? And so would that. Tell you what: if you have suggestions for or run into problems with the Deleteomatic, drop us a line at cspshell@microsoft.com and we'll see what can do. In the meantime, enjoy version 1.0, and keep your eye for our upcoming series of articles that explain how you can write your own Deleteomatic.

 

And no, sorry: we have no plans for a series explaining why you might want to write your own Deleteomatic. You're on your own there.

 

OK, so if you could have your absolute dream job, what would it be?

 

Wow, that really would be a great job, wouldn't it? Listen, if you decide not to apply for that, could you let us know? Thanks!

 

Let's rephrase our original question: if you couldn't get your absolute dream job then what job would you like to have? That's the answer we were looking for: you'd want to work for the Microsoft Lync Server team, the same team that produces, well, Microsoft Lync Server. Of course, who wouldn't want to work for the Lync Server team, who wouldn't want the chance to help produce the next version of the coolest, most-innovative piece of software on the planet? (Or planets, for that matter: we don't think they have anything on Mars that compares with Lync Server.) But let's be honest: what are the odds that you could get the chance to work on the Lync Server team? After all, a high-powered team like the Lync Server team probably doesn't even advertise when it has open positions; instead, it probably goes around the world and handpicks only the best and the brightest.

 

Present company excepted, of course.

 

Amazing enough, however, that's not how Lync Server does things: not only do we advertise our open positions, but at this very moment we're advertising three open positions! If all goes well, that means that you really could come work for the Lync Server team.

 

Which, in all seriousness, would be way cool.

 

So what three positions do we have available? For starters, the manageability team (the team that, among other things, is responsible for Lync Server's implementation of Windows PowerShell) is looking for a pair of software development engineers. Those engineers will help to "… build the tools used to keep the service running, automatically reimage and redeploy servers, and manage a complex global deployment from a single console." If that's not a dream job, well, we don't know what is.

 

Of course, there is a catch: qualified applicants " … need to write reliable, readable, rock-solid code in C#, PowerShell, SQL and C++, and interface with WDS, AD, numerous SQL servers, Windows Workflow, Azure and many more." Wow. But if that sounds like you, and you think you might be interested, you can find more information about the two positions here:

 

·         https://careers.microsoft.com/JobDetails.aspx?ss=&pg=0&so=&rw=16&jid=53300&jlang=EN

·         https://careers.microsoft.com/JobDetails.aspx?ss=&pg=0&so=&rw=15&jid=64381&jlang=EN

 

 

If software development isn't your thing then maybe you'd be interested in our third opening: Software Engineer II. If you're wondering what a Software Engineer II does, well, a Software Engineer II helps to " … support Service Deployment, Activation, Administration, Troubleshooting, Root Cause Analysis, User Management, Monitoring and Optimization." If you like getting your hands dirty, and if you'd like to really know how Lync Server works, then this is the job for you.

 

And yes, as a matter of fact you do need to be qualified to do this job, too; among other things, this position "… requires strong technical knowledge and advance skills in ADFS, LDAP, ADSI, Kerberos/ NTLM / Certificate authentication, PowerShell Scripting, DNS, SIP, TCP/IP, and other network protocols."  If you have those skills, well, we can't think of a more interesting, and more challenging, environment in which to put those skills to the test.

 

You say you'd like more information on this position? All you had to do was ask:

 

·         https://careers.microsoft.com/JobDetails.aspx?ss=&pg=0&so=&rw=1&jid=65564&jlang=EN

 

We strongly encourage everyone to take a look at the job postings and see what you think; if you think "Wow, I would love to have this job," well, you can apply right online. (Just get a fresh copy of your resume our and then click the button that's somewhat-mysteriously labeled Apply to job.) If you'd like more information about the positions then drop us a note at cspshell@microsoft.com. We can't promise that we'll be able to answer every question, but we'll do our best. And on your first day of work here, we'll take you out for a cup of coffee, on us!

 

What do you mean "And a doughnut?" Tell you what: get the job first, and then we'll go from there.

 

 

 

 

Some of the writers on the Lync PowerShell blog have been accused at times of not being very good listeners. And when we say “some” of the writers we mean one of the writers has been accused of that – mostly by the other writer. But today we both decided to listen. Not to each other, of course, but to you, our devoted readers.

 

In July we posted the Lync Server Administration Guide: PowerShell Supplement to this blog. We did this because the Lync Server Administration Guide, although a very useful thing to have, didn’t have a lot of PowerShell in it. So we decided to show you how you can do all the things in the Admin Guide by using PowerShell. And people seemed to appreciate that. But here’s where the listening came in: As nice as it is to have this supplemental information posted on a blog, we were told it would be even nicer to provide it in one nice, neat, downloadable document. We agreed, which is why you can now download the Lync Server Administration Guide: PowerShell Supplement as a Microsoft Word document.

 

Did we hear applause out there somewhere? See, our hearing is getting better all the time. (We’re still working on the listening.)

 

 

 

 

For those of you who were following our Haiku of the Day, you know that the haiku writer spent a month hiking and biking around Park City, Utah. Now that he’s back, he has absolutely nothing to say and so has stopped writing the daily haiku.

 

Okay, that’s not entirely true. He did stop writing the daily haiku, but only because he ran out of Lync Server cmdlet nouns. Will the Haiku of the Day begin again if and when Lync Server releases new cmdlets? Well, we’ll have to think about that one. It depends on whether anything interesting is going on in the haiku writer’s life at the time. (Which makes the prospect doubtful.)

 

In the meantime, haikus for all the cmdlets that shipped with Lync Server 2010 are available to you in the Haiku Archive.

 

 

Tip of the Month

 

Need help with using a Lync PowerShell cmdlet? Of course, you can always type Get-Help at the command prompt, like this:

 

Get-Help New-CsVoicePolicy –Full

 

But this is the help that originally shipped with the product. We’ve made a few updates since then. If you want the most up-to-date help available, you need to go to the web. Here’s an easy way to do that:

 

Get-Help New-CsVoicePolicy –Online

 

Assuming you have an Internet connection, this command takes you straight to the updated help on TechNet for the cmdlet of your choice (in this case, New-CsVoicePolicy).

 

 

What Happened at the Lync Server PowerShell Blog in September

 

To be honest, very little happened in the blog in September. About all we did was post haikus for the final 13 Lync Server cmdlet nouns:

 

 

·         CsStaticRoutingConfiguration

·         CsDatabase

·         CsUserAcp

·         CsOutboundTranslationRule

·         CsVoiceConfiguration

·         CsClientVersionPolicyRule

·         CsCertificateConfiguration

·         CsTrustedApplicationComputer

·         CsRgsWorkflow

·         CsClientPolicy

·         CsVoiceRoute

·         CsDeviceUpdateRule

·         CsCertificate

 

 

From the Community

 

Here are some things from elsewhere in the Windows PowerShell and Lync Server world:

 

Automatically enable users in a particular OU for Lync 2010

From Akshat N, a blog post the presents a “quick and dirty way” to schedule a task that will automatically Lync-enable any users in an OU who have not yet been enabled.

 

PowerShell V3 and Updateable Help

If you haven’t taken a peek at what’s happening with Windows PowerShell v3, here’s an interesting little feature discussed on Thomas Lee’s blog. This doesn’t have anything to do with Lync Server 2010, but it never hurts to see what’s going on in the world of PowerShell in general.

 

 

 

 

 

 

 

Turn out the lights, the

Party's over: today's our

Last haiku (for now).

 

Today is a very auspicious, and somewhat sad, occasion: it marks, for the moment anyway, the end of the Lync Server PowerShell Haiku of the Day. (Trust us, we thought this day would never come, either.) Believe it or not, by the time today's haiku is finished we'll have worked our way through all the Lync Server PowerShell nouns. In turn, that means we can't have any more haikus, at least not until we have some more Lync Server PowerShell nouns to work with.

 

 

So what does this all mean for the Lync Server PowerShell blog? Well, to be honest, we're not totally sure about that. We'll continue to post articles to the blog, and we'll continue to keep you as up-to-date as possible on Lync Server PowerShell. But what it actually means to "keep you as up-to-date as possible" is still to be determined. Why? Well, for one thing, now that we're done writing haikus, our managers think maybe it might be time for us to do some real work.

 

 

But hey, we'll worry about tomorrow come tomorrow. As for today, we thought we'd spend a large portion of our time reviewing some of the great moments and happy memories from the Lync Server PowerShell Haiku of the Day:

 

·          

 

OK, well, apparently there aren't quite as many great moments and happy memories as we thought. (But hey, we'll always have the story of Planet Nibiru, right?) With that in mind, there's only one thing left to do: talk about the CsCertificate cmdlets (Get-CsCertificate, Import-CsCertificate, Remove-CsCertificate, Request-CsCertificate, and Set-CsCertificate).

 

Before we begin we should probably note that we aren't exactly experts when it comes to certificates, let alone Lync Server certificates. (What's that? But we were experts on all the other topics we covered in our previous haikus? Well, maybe not experts, mind you ….) We'll try to give you an overview of what the CsCertificate cmdlets do, but if you're thinking, "I should ask these guys if it's a good idea to use wildcards in my SANs," well, then you should probably think a little harder.

 

But hey, give us a break: after all, we are haiku writers. Would you ask Masaoka Shiki if it's a good idea to use wildcards in your SANs?

 

Although even he'd probably know more about that than we would.

 

 

We thought we'd kick things off by talking a little bit about the Request-CsCertificate cmdlet. Request-CsCertificate is actually a remarkably clever cmdlet: you simply tell Request-CsCertificate that you need a certificate, and it does a lot of the work involved in figuring out what kind of certificate you need and how to configure that certificate. For example, suppose you request a WebServicesExternal certificate. If you do that, request-CsCertificate will read your topology and automatically add the Simple URLs for meet and dialin (as well as your reverse proxy URL) to the Subject Alternative Name field. What's that? You say there's also a third Simple URL: admin? Yes, there is. But typically you don't want to expose your admin URL to the outside world. And Request-CsCertificate is smart enough to know that.

 

Like we implied earlier, certificates can be a … challenge … to work with. Because of that, we won't run through all the different parameters available when running Request-CsCertificate; we could start a whole new haiku series just on those. (But don't worry: we won't start a whole new haiku series on Request-CsCertificate parameters.) Instead, we'll just give you an idea of what a command asking for a new certificate might look like:

 

Request-CsCertificate -New -Type Default,WebServicesInternal,WebServicesExternal -ComputerFqdn "atl-cs-001.litwareinc.com" -CA "atl-ca-001.litwareinc.com\myca" -FriendlyName "Enterprise Edition Pool Certificate" -Template jcila -PrivateKeyExportable $True -DomainName "pool1.litwareinc.com,pool1int.litwareinc.com,pool1ext.litwareinc.com"

 

Like we said, this can be a bit of a challenge.

 

 

When you use Request-CsCertificate (or the Certificate Wizard) to make an online request for a new certificate, that new certificate will be retrieved and will automatically be available to use with Lync Server. But what if you make an offline request, or what if you have certificates that weren't obtained using Request-CsCertificate? That's fine; if you have certificates that were acquired without using Request-CsCertificate (or the Certificate Wizard) you can still use those certificates with Lync Server. All you have to do is use the Import-CsCertificate wizard to, for all intents and purposes, let Lync Server know that the certificate exists:

 

Import-CsCertificate -Path "C:\Certificates\WebServer.cer" -PrivateKeyExportable $True

 

And after the certificate has been imported, you can then use Set-CsCertificate to assign that certificate to a Lync Server server or server role:

 

Set-CsCertificate -Type WebServicesExternal -Thumbprint "B142918E463981A76503828BB1278391B716280987B"

 

What did we tell you? Certificates can be a challenge, but the CsCertificate cmdlets are anything but a challenge.

 

That leaves just two cmdlets to talk about: Remove-CsCertificate and Get-CsCertificate. As you might expect, Remove-CsCertificate removes a Lync Server certificate. Except, to be a bit more accurate, it doesn't really remove the certificate: the certificate will remain on your computer and can be used for other purposes. Instead, Remove-CsCertificate simply marks the certificate as no longer being available for use by Lync Server, removes any certificate bindings, and revokes access permissions to the certificate. The certificate will still exist, but Lync server won’t know that: if you run the Get-CsCertificate cmdlet that certificate will not show up.

 

Speaking of which, now might be as good a time as any to mention that Get-CsCertificate returns information about your Lync Server certificates. (And only your Lync Server certificates: if a certificate wasn't obtained using Lync Server or wasn't imported using Lync Server, well, then Get-CsCertificate won't return information about that certificate.) You say you want to see information about all your Lync Server certificates? Then just run this command:

 

Get-CsCertificate

 

Want information about just the Default certificate? Then use this command:

 

Get-CsCertificate –Type Default

 

How about all the certificates that don't include sip.fabrikam.com in the AlternativeNames property? Sure; why not:

 

Get-CsCertificate  | Where-Object {$_.AlternativeNames -notcontains "sip.fabrikam.com"}

 

Etc., etc.

 

The only drawback to the Get-CsCertificate cmdlet is that it only returns certificates from the local computer. You say you need certificate information from a remote computer? Then you're either going to have to log on to that remote computer or connect to it using remote PowerShell in order to get that data.

 

But, then again, nobody's perfect right? With the possible exception of Masaoka Shiki, of course.

 

 

That's pretty much all we have to say about the CsCertificate cmdlets. Typically we sign off each day by saying "See you tomorrow," not because that was a clever way to sign off but simply because we could never actually come up with a clever way to sign off. But now that the daily haiku series is done for a while, we can't just end things by saying "See you tomorrow." So, we'll just end things.

 

 

 

 

 

 

 

 

 

If a tree falls in

The forest then it's his fault.

Device update rules.

 

Here's something that will shock you: the author of today's haiku is a cold-blooded killer.

 

 

As it turns out, yesterday the author of today's haiku printed out a one-page checklist of things he needs to look into for an upcoming documentation project. When he went to pick up his one page (front and back) checklist, the cover sheet attached to the printout included this blood-curdling message:

 

You just killed a tree

 

As you might expect, the author of today's haiku was stunned to hear that he had just killed a tree. After all, the author of today's haiku has always fancied himself something of a conservationist, and has always been a dedicated recycler. For example, back when his son used to get action figures for Christmas, the author of today's haiku would dutifully tear apart the packaging for those action figures, tossing out the plastic, but recycling the cardboard. For someone like that to kill a tree, well, that wasn't exactly the best news he got all day.

 

 

So how can the author of today's haiku defend himself? Well, truthfully, he can't: after all, he did click the Print button. Still, he did only use up a single piece of paper (the same amount of paper required for the cover sheet). And he does wonder this: if it takes an entire tree to make one piece of paper, shouldn't we maybe look for a different paper supplier? But no excuses: what's done is done.

 

To make matters even worse, this isn't the first time he's been accused of killing trees. Every month when he gets his bill from the cable company, that bill includes a memo noting that he could have saved a tree by switching to electronic billing. That bill also includes a ton of advertisements for other services the cable company offers but that the author of today's haiku has yet to sign up for. The bill also includes flyers for the cable company's on-demand service (because the author of today's haiku is likely to be thinking, "I demand to see Shark 3D, right now!) and for upcoming pay-per-view extravaganzas like WrestleMania  (can you believe we're up to WrestleMania XVII already; where does the time go?) and the next UFC championship bout (Quinton "Rampage" Jackson vs. Anne Hathaway). The author of today's haiku isn't trying to justify the fact that he killed a tree by not switching to electronic billing; he's just wondering how many trees the cable company killed by including all that wasted paper in his bill?

 

 

But enough about that. By now you're probably wondering, "So what does the author of today's haiku do when he isn't singlehandedly deforesting the world?" And here's your answer: he uses the CsDeviceUpdateRule cmdlets (Approve-CsDeviceUpdateRule, Get-CsDeviceUpdateRule, Remove-CsDeviceDeviceRule, Reset-CsDeviceUpdateRule, and Restore-CsDeviceUpdateRule) to manage the device update service.

 

Hey, even cold-blooded killers need to have a hobby, right?

 

So what's so great about the CsDeviceUpdateRule cmdlets? Two things. First, they're environmentally-friendly: even the author of today's haiku rarely kills a tree when running these cmdlets. (Hey, we said rarely.) Perhaps more important, they serve a very useful function when it comes to managing Microsoft Lync Server 2010.

 

And what is that useful function? Well, as you know (because you did read Haiku #145, didn't you?) Lync Server uses the device update service to provide a way to push firmware updates to devices that run Microsoft Lync Phone Edition. These firmware updates are periodically published by Microsoft, and administrators can easily get a copy of the updates and then upload the update files to Lync Server. From there, the updates can then be distributed to the appropriate phones and devices.

 

You know, that's a good point: there have been times when updates have created more problems than they solved, haven't there? But don't worry: the Lync Server product team already thought of that. When you upload your device update "rules" (a rule is simply an update for a particular type of device, such as LG-Nortel cell phones) each rule is marked as being in a Pending state. When a rule is marked as Pending, that means it does not get pushed out to all the relevant devices. Instead, the update is only installed on predefined test devices. After administrators have verified that the update is working properly on the test devices then the update rule can be marked as being Approved. That update will then be automatically downloaded and installed on all the relevant devices (for example, all the LG-Nortel cell phones).

 

So how does a device update rule get approved? Why, by calling the Approve-CsDeviceUpdateRule cmdlet, of course:

 

Approve-CsDeviceUpdateRule -Identity service:WebServer:atl-cs-001.litwareinc.com/d5ce3c10-2588-420a-82ac-dc2d9b1222ff9

 

Admittedly, that's an … interesting … little command. (Please don't print it out; the author of today's haiku has killed enough trees as it is.) The problem, as you can see, is that each device update rule has an Identity that consists of the Web server the rule was imported to plus a GUID (globally unique identifier). That makes it easy to uniquely pinpoint a given rule, but somewhat less easy to actually type in a command that approves that rule.

 

But don't despair: with clever use of the Get-CsDeviceUpdateRule cmdlet you can typically avoid having to work with rule Identities. For example, suppose you have only one update rule that refers to LG-Nortel phones. Perfect; that means you can use a command like this to retrieve (and approve) that rule:

 

Get-CsDeviceUpdateRule | Where-Object {$_.Brand -eq "LG-Nortel"} | Approve-CsDeviceUpdateRule

 

That's a little bit easier, to say the least. And if you need to get a little fancier (say you only want to approve a specific model of the LG-Nortel phone), well, then just get a little fancier:

 

Get-CsDeviceUpdateRule | Where-Object {$_.Brand -eq "LG-Nortel" –and $_.Model –eq "IP8540"} | Approve-CsDeviceUpdateRule

 

With the Get-CsDeviceUpdateRule cmdlet you can filter on such things as:

 

·         Device type (typically UCPhone)

·         Brand

·         Model

·         Revision

·         Locale

·         UpdateType

·         ApprovedVersion

·         RestoreVersion

·         PendingVersion

 

Pretty cool, huh?

 

As we noted, when you first upload device update rules each rule is marked as Pending; that simply means that the rule version number will be assigned to the PendingVersion property:

 

ApprovedVersion :

RestoreVersion  :

PendingVersion  : 4.0.7168.0

 

When you approve a rule, that version number gets assigned to the ApprovedVersion property and the PendingVersion is set to a Null value:

 

ApprovedVersion : 4.0.7168.0

RestoreVersion  : 4.0.6991.0

PendingVersion  :

 

So how do you get a list of rules that have been approved? Like this:

 

Get-CsDeviceUpdateRule | Where-Object {$_.ApprovedVersion –ne $Null}

 

In other words, if a rule has been approved then the ApprovedVersion property will be equal to something.

 

And to get a list of rules still in the Pending state? You got it:

 

Get-CsDeviceUpdateRule | Where-Object {$_.PendingVersion –ne $Null}

 

That just leaves us with the RestoreVersion property and, by extension, the Reset-CsDeviceUpdateRule cmdlet and the Restore-CsDeviceUpdateRule cmdlet. (We're going to take it on faith that you've already figured out that the Remove-CsDeviceUpdateRule cmdlet removes a device update rule.)

 

Let's start off by talking about what the Reset-CsDeviceUpdateRule cmdlet does. As we noted earlier, each device update rule begins life by being marked as Pending; as we also noted, that enables administrators to test the update before making it available to users. If the update seems to be working then administrators can mark the update as approved.

 

Ah, but suppose the update is not working. In that case, administrators can run the Reset-CsDeviceUpdateRule cmdlet against that rule:

 

Get-CsDeviceUpdateRule | Where-Object {$_.Brand -eq "LG-Nortel"} | Reset-CsDeviceUpdateRule

 

What's the point of that? Well, when you do that, the value of the PendingVersion property gets set to null:

 

ApprovedVersion:

RestoreVersion:

PendingVersion:

 

And what's the point of that? Well, when PendingVersion is set to null, the update in question will be uninstalled from the test devices; in addition, the test devices will re-install their most recently-approved update. With PendingVersion set to null test devices won't bother with the update. And with ApprovedVersion set to null, user devices woin't bother with the update, either.

 

Of course, PendingVersion only works with rules that are in the Pending state; that is, rules that have never been approved. Now, suppose you approve a rule and only later discover that the update is causing problems. In that case, Reset-CsDeviceUpdateRule won't do you any good; instead, you'll need to run the Restore-CsDeviceUpdateRule cmdlet instead:

 

Get-CsDeviceUpdateRule | Where-Object {$_.Brand -eq "LG-Nortel"} | Restore-CsDeviceUpdateRule

 

So what does that command do? Well, we kind of skipped over this earlier, but when you approve a device update rule three things actually happen: 1) the PendingVersion is set to a null value; 2) the ApprovedVersion is set to the version of the newly-approved update rule; and, 3) the RestoreVersion is set to the version number of the rule that was previously-approved for this device. Remember this output:

 

ApprovedVersion : 4.0.7168.0

RestoreVersion  : 4.0.6991.0

PendingVersion  :

 

That output tells us that, prior to approving rule 4.0.7168.0, we had approved rule 4.0.6991.1.

 

Why do we care about the previously-approved rule? Well, we've just discovered that our new rule (rule 4.0.7168.0) doesn't work. If we run the Restore-CsDeviceUpdateRule cmdlet here's what happens:

 

ApprovedVersion : 4.0.6991.0

RestoreVersion  :

PendingVersion  :

 

See? What Restore-CsDeviceUpdateRule does is take the old rule and make that old rule (4.0.6991.0) the ApprovedVersion. What difference does that make? Well, that will cause all the affected devices to uninstall update 4.0.7168.0 and reinstall 4.0.6991.0. In other words, we put things back the way they were before we installed the update.

 

 

Got all that? Admittedly, it's a little complicated, at least at first glance. But it's actually a pretty good system, and it even makes sense once you think about it a bit.

 

Really.

 

See you tomorrow.

 

 

 

 

 

 

 

 

 

 

Seahawk football? Thanks.

But we'll just play with voice route

Cmdlets instead.

 

Well, autumn officially arrived in the Pacific Northwest this past weekend. How do we know that? Well, for one thing, the weekend was cold and damp, which is – well, never mind; come to think of it, it's pretty much always cold and damp here, regardless of the season. On top of that, the Seattle Mariners lost two more games this weekend, meaning they have no chance to – well, OK, never mind. Not a good example, either.

 

Wait, here's one: both of our football teams, the Seattle Seahawks and the University of Washington Huskies, got beat this past weekend.

 

 

Now, in all fairness, we should point out that both the Seahawks and Huskies were obviously victims of budget cuts and the economy. With money as tight as it is, the Seahawks were only able to send their defense to Pittsburgh and were forced to leave their offense at home. (And yet, despite that, the team still managed to cross the midfield stripe – twice.) The Huskies, beset by the same budget woes, decided to leave their defense at home, and, as a result, dropped a 51-38 decision to Nebraska. To put that in perspective, the 1991 Husky team that won the national championship gave up 101 points. That's 101 points over the entire 12-game season. In three games this year, the Huskies have already given up 110 points.

 

Autumn is such a delightful season.

 

Speaking of which, there's one other sign that autumn has arrived: we're almost done with the daily Lync Server PowerShell haiku. In fact, after today we'll have just two more nouns to cover: CsCertificate and CsDeviceUpdateRule. At that point, we'll have written haikus for all the Lync Server PowerShell nouns, something they said could never be done!

 

Or maybe it was something they said should never be done. But you get the idea.

 

At any rate, we'll have more about the haiku of the day – and our future plans for the Lync Server PowerShell blog – later. Today we have something way more important to talk about: the state of football in the Pacific Northwest.

 

On the other hand, based on the results of this past weekend, there really isn't much to talk about when it comes to football in the Pacific Northwest. So let's talk about the CsVoiceRoute cmdlets instead: Get-CsVoiceRoute, New-CsVoiceRoute, Remove-CsVoiceRoute, and Set-CsVoiceRoute. Oh, and Test-CsVoiceRoute, too.

 

 

As you probably know, voice routes are used to route calls from Enterprise Voice users to phone numbers on the public switched telephone network (PSTN) or a public branch exchange (PBX) system. Without getting too technical (in large part because we can't get too technical when it comes to voice routes), any time an Enterprise Voice user places a call Lync Server converts the dialed number to the E.164 format and then tries to match that E.164 number to a SIP URI. If the E.164 number can't be matched to a SIP URI Lync Server then uses voice routes to determine how the call should be handled. For example, if the dialed number is 1-206-555-1219 a voice route would figure out that this is a call to a US phone number and send the call to the appropriate PSTN gateway. If the dialed number is 44-113-555-1219 a different voice route would recognize that this is a call to a number in the United Kingdom (country code 44) and, in turn, might route the call to a different PSTN gateway. Admittedly, that's a somewhat simplistic explanation of voice routes and how they work, but it'll do for now.

 

As for how you create a voice route in the first place, well, here's one example:

 

New-CsVoiceRoute -Identity RedmondVoiceRoute -PstnUsages @{add="Long Distance"} -PstnGatewayList @{add="PstnGateway:redmondpool.litwareinc.com"}

 

This happens to be a very basic voice route: it simply specifies an Identity (RedmondVoiceRoute) as well as one PSTN usage and one gateway. (A single route can support multiple PSTN usages and/or multiple gateways.) You can actually create a voice route that doesn't have a PSTN usage or a PSTN gateway; for example, this is a perfectly valid Lync Server PowerShell command:

 

New-CsVoiceRoute -Identity RedmondVoiceRoute

 

That command will create a voice route, but it will be a totally useless voice route: without a PSTN usage or a PSTN gateway, the route will not be able to forward calls; in turn, that means that your users won't be able to actually place phone calls. The moral of the story? It doesn't make a whole lot of sense to create a voice route that doesn't have at least one PSTN usage and at least one gateway.

 

 

Incidentally, the voice route we just created basically matches any E.164 number. In turn, that means that any number that gets dialed will be scooped up by this voice route and forwarded to the gateway redmondpool.litwareinc.com. How do we know that? Well, by default the NumberPattern property for a voice route is set to this:

 

[0-9]{10}

 

That's an odd-looking value, yes, but it's a regular expression that basically says this: if you see a phone number that consists solely of the digits 0 through 9 and that phone number is at least 10 digits long, well, then we've got a match. Needless to say, that's going to basically be any phone that gets converted to the E.164 format. But what if you only wanted to match calls made to the 206 area code in the US? In that case, you'd need to change the NumberPattern. For example:

 

-NumberPattern "^1206[0-9]{7}"

 

Without going into any details, that matches any number that starts with the value 1206, and then is followed by 7 digits. For example:

 

12065551219

 

The other thing you might need to do here is set the Priority for the voice route. As you might recall, the first voice route we created captures pretty much any E.164 phone number; that means it will capture phone calls made to the 206 area code. How do we make sure that our other voice route captures calls made to the 206 area code? One sure-fire way is to set the Priority of the route to 0:

 

-Priority 0

 

If you run into a situation where multiple voice routes match a given phone number, Lync Server will use the route that has the lowest Priority value. And 0 is the lowest priority.

 

By the way, here's the full command that creates a voice route that matches 206 numbers and has a Priority of 0:

 

New-CsVoiceRoute -Identity 206AreaCodeVoiceRoute -PstnUsages @{add="Long Distance"} -PstnGatewayList @{add="PstnGateway:redmondpool.litwareinc.com"} -NumberPattern "^1206[0-9]{7}" –Priority 0

 

And before you ask, yes, this can get complicated. Which is at least one reason why you should carefully plot out your voice routing strategy before you begin creating new voice routes willy-nilly.

 

Seeing as how New-CsVoiceRoute is used to create new voice routes, it probably comes as no surprise that Remove-CsVoiceRoute is used to remove existing voice routes; Get-CsVoiceRoute is used to return information about existing voice routes; and Set-CsVoiceRoute is used to modify existing voice routes. What kind of things would you ever need to modify in a voice route? Well, here's an interesting example. By default, any call placed using a given voice route will end up displaying the caller's phone number in any Caller ID system. For example, suppose Ken Myer has the phone number 555-0712 and he places a call to Pilar Ackerman. What number is going to show up on Pilar's Caller ID? This number:

 

5550712

 

That's fine, but suppose you'd rather have your company's phone number (5551234) show up on Caller ID systems, regardless of whether Ken Myer or anyone else places the call. Can you do that? Sure you can. All you have to do is set the SuppressCallerId property to True, and then specify the number to be displayed as the value of the AlternateCallerId number. You know, like this:

 

New-CsVoiceRoute -Identity 206AreaCodeVoiceRoute –SuppressCallerId $True –AlternateCallerId "5551234"

 

Just a little something you might find useful.

 

Another little something you might find useful is the Test-CsVoiceRoute cmdlet, which lets you verify that a given phone number will match the NumberPattern for a given voice route. In order to use the Test-CsVoiceRoute cmdlet you need to do two things. First, you need to use the Get-CsVoiceRoute cmdlet to retrieve an object reference to the voice route being tested. For example:

 

$x = Get-CsVoiceRoute "206AreaCodeVoiceRoute"

 

Second, you need to then use that object reference plus the number being dialed in your call to Test-CsVoiceRoute:

 

Test-CsVoiceRoute -TargetNumber "12065551212" -Route $x

 

The preceding test should return True. Why? Because the NumberPattern for the 206AreaCodeVoiceRoute is supposed to match any phone number that starts with 1206 and then is followed by at least 7 digits. This command should return False:

 

Test-CsVoiceRoute -TargetNumber "14255551212" -Route $x

 

Why? You got it: because the target number does not start with 1206. And this command will fail because, although the target number starts with 1206, it's not followed by 7 digits:

 

Test-CsVoiceRoute -TargetNumber "1206" -Route $x

 

Could we just sit around and run voice route tests all day? You bet we could. But that's mainly because, here in the Pacific Northwest, we don't have any football games worth watching. Those of you who live in Kansas City (and have watched your beloved Chiefs get outscored 89-10 this season) know exactly what we’re talking about.

 

See you tomorrow.