Tag Archives: providers

PowerShell The Community’s Command Line Part 27 of 31: It Takes a Community to Raise a Language

Much like the saying It takes a village to raise a child, it takes a community to raise a programming language. Without passionate people in that community, the word won’t spread and a language can die. Yesterday, I talked about some of the cool community resources and sites. Today, I want to salute those who are working on community projects with PowerShell. These are just a few of the many out there.

StudioShell, by Jim Christopher (@beefarino)

http://studioshell.codeplex.com/
StudioShell is an integrated PowerShell host available inside Visual Studio 2010 and 2008. This tool exposes Visual Studio’s extensibility points and makes it easier to extend your Visual Studio from the command line rather than from compiled binaries. Jim will be giving a presentation on his StudioShell project and using it to extend Visual Studio at CodeStock 2011 down in Knoxville, TN this June.

MongoDB PowerShell Provider, by Jim Christopher

http://mosh.codeplex.com/
If you’re in an environment where you need to manage a Mongo database, then the MongoDB PowerShell Provider may make your life a little easier in managing the database from within PowerShell. This project is nicely documented both on the CodePlex site and from within PowerShell.

PowerShell Script Provider, by Oisin Grehan (@oising)

http://psprovider.codeplex.com/
While developers who can think out a provider’s logic may be more comfortable with writing the provider in C#, this provider allows IT Pros and those comfortable with PowerShell to write their providers in the PowerShell scripting language. Oisin Grehan, PowerShell MVP and PowerShell provider guru, is the guy behind this project. It’s great to see the option of writing providers in PowerShell, as working with the scripting technology directly in its own language makes more sense to many scripters.

Show-UI: The PowerShell WPF Toolkit

Show-UI
For those who have our book, disregard the recommendations on page 397 on the two things to help with WPF apps in PowerShell, as WPK and PowerBoots are merging. Show-UI is the project that they are merging into. Yes, you can use PowerShell to create GUIs. Show-UI is a project that can help make that process even easier in PowerShell. Shoutouts to the coordinators and developers – Jaykul, Doug Finke, and James Brundage.

Others?

Got any other PowerShell projects that you want to share? Leave me a comment!

PowerShell Not Your Father’s Command Line Part 14 of 31: Sorry I’m Not Home Right Now, Walking into IIS Webs…

Sorry I’m not home right now
Walking into IIS Webs
Just leave a message and I’ll call you back – No Doubt, if they were techies

So today we’re going to look into the IIS provider in PowerShell. If you aren’t familiar with PowerShell providers, check out Matt’s post on PowerShell providers. If you’re dealing with IIS 7.0, you’ll want to look into the IIS PowerShell snap-in. Otherwise, if you’re dealing with IIS 7.5, you’ll want to look into the IIS PowerShell module. Today’s post will be looking at IIS 7.5 and the WebAdministration module.

First things, first!

In order to work with the IIS module, you need to start a PowerShell session with elevated permissions. If you don’t, then you’ll get an error like this:

PS C:\users\sdutkiewicz:> Import-Module WebAdministration
Process should have elevated status to access IIS configuration data.

Once you start PowerShell as an administrator, you can use Get-Module to see if the WebAdministration module is loaded. If it isn’t loaded, then run:

Import-Module WebAdministration

The module is loaded. What kind of goodies are in the IIS module?

A lot of IIS functionality that you’re used to in the GUI is also available in the WebAdministration module, packed into a variety of cmdlets. There are cmdlets to help with:

  • web configuration
  • websites
  • web applications
  • application pools
  • web bindings

To see a full list of cmdlets, aliases, and functions included in the WebAdministration module, run the following command:

Get-Command -Module WebAdministration

You mentioned an IIS provider…

Yes, I did! If you run the following command, you’ll see a list of providers installed:

Get-PSProvider

You should see a provider named WebAdministration, which includes an IIS drive. Let’s see what it allows us to explore.

Set-Location IIS:

If we run a Get-ChildItem at this point, we’ll see that the IIS provider lets us navigate through 3 parts of IIS – AppPools, Sites, and SslBindings. Today, we’ll look at Sites, as they are the central point. The Sites folder in the IIS provider contains websites, web applications, and virtual directories. From the IIS: prompt, run the following command:

Set-Location Sites

If you run the Get-ChildItem command at this point, you should see the list of sites setup on your web server. It may look like the picture below:

Sarah's demo websites

You’ll notice that my sadukievents site shows a state of being stopped. We can easily fix this using one of the cmdlets included in the WebAdministration module:

Start-Website sadukievents

Notice how simple it was – no need to remember an IIS metabase path! Now let’s say that same site was getting carried away with the resources and we needed to stop the site. The Stop-Website cmdlet works similarly. Of course, sites rarely misbehave at an appropriate time. When you open PowerShell as an administrator, you’re dropped at your system folder (unless you’ve altered that). Rather than changing to the IIS drive and stopping the site (whose name you already know), you can run this command from your current drive with the following command:

Stop-Website sadukievents

Now back to IIS:\Sites… what do you see once you change directories into a Site? When you run Get-ChildItem (or its built-in alias of dir) on a site, it shows you the contents of the site. The image below shows what’s in the sadukievents website:

directory listing of the sadukievents website

You can see that the output from this particular folder looks like a directory listing – showing the file mode, last write time, length, and name. This appears this way because these are all files or directories. What if there was a virtual directory or possibly a web application in this folder? Then the output changes to show the type (application, directory, file, or virtualDirectory), name, and physical path. You can see a sample of this below:

directory listing of the sadukievents website with modules and virtual directories

At this point, you should feel comfortable navigating through the Sites folder. You can use Get-ChildItem and Set-Location to navigate through the AppPools and SslBindings folders in the same way, learning more about the AppPools and SslBindings.

So that’s navigation. Can we do anything else in here?

Besides navigating the IIS drive, you can also use it much like you would other PowerShell provider drives. When working with IIS cmdlets from outside of the IIS drive, you can reference the IIS drive as a path. For example, let’s say you’re working in a clustered web environment due to high-availability requirements and need to setup a new website on all the servers in the cluster. Sure, you could do it manually on each server, but why waste your time when you can script it? Here’s a sample command for creating a new web application:

New-Item ‘IIS:\Sites\Sadukieville’ -Type Application -PhysicalPath d:\Websites\Sadukieville

If that example web application had a virtual directory for a bakery site within it, it may be scripted like this:

New-Item ‘IIS:\Sites\Sadukieville\Bakery’ -Type VirtualDirectory -PhysicalPath c:\inetpub\wwwRoot\sadukieria

Both of the above examples show how you can use the IIS provider as a path with other cmdlets. Of course, there’s plenty more that you can do. For more information, explore the cmdlets as suggested above, and know that Get-Help and Get-Help command -examples are at your fingertips to guide you through how those cmdlets work and how you can take advantage of the IIS provider while scripting your web administration tasks.


Do you have specific questions about PowerShell that you want answered? Whether it’s IT pro related or developer related, I can probably help! Drop me a line at sarah at codinggeekette dot com, and I’ll try to cover your questions in an upcoming blog post.

Matt and I love feedback from our readers, so please email us if you have comments or suggestions.

PowerShell Not your Father’s Command Line Part 13 of 31: The Provider Active Directory Style

Matt and I really are huge fans of PowerShell providers. After talking about them in general and focusing on the registry provider, you think that we’d stop. But no… there are two more days of this talk of providers – Matt is going to talk about the Active Directory provider today, and I’m going to talk about the IIS provider tomorrow. Yes, providers make our administration tasks much easier by getting us access to things that are typically a little harder to script. This makes it easier for IT pros to write scripts that take advantage of these providers and automate more of their day-to-day operations.

Do you have a favorite provider? Tell us about it! Leave us comments on our blogs or email us. You can reach me at sarah at codinggeekette dot com.

PowerShell Not your Father’s Command Line Part 12 of 31: PowerShell and The Registry

Yesterday, Matt and I talked about providers, and I mentioned that I wasn’t going to go on talking about the registry provider, as that’s what Matt is talking about today! What’s nice is that you don’t have to type out HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER while working with this provider. You can refer to them by HKLM and HKCU, respectively.

However, those are the only 2 registry hives that are provided for. So if you are working with the other hives (HKEY_CLASSES_ROOT, HKEY_USERS, and HKEY_CURRENT_CONFIG), you will have to rely on your previous knowledge of accessing them to work with them. There are no HKCR, HKU, or HKCC drives to help out in this case.

PowerShell Not your Father’s Command Line Part 11 of 31: PowerShell Providers and You!

Today, Matt is going to tell you about the awesomeness known as PowerShell providers. I have to admit that providers really are helpful. Sure, there are the PowerShell-specific providers – Alias, Function, and Variable. These can tap into the PowerShell system and help you determine what aliases, functions, and variables already exist. But then there are other providers that are there to make it easier to access data stores that are typically hard to access in a scripting environment.

Matt will talk about the registry provider tomorrow, so I won’t go on about it here. The other built-in providers give us access to the file system objects (FileSystem provider), X.509 certificate store (Certificate provider), environment variables (Environment provider), and Web Services for Management (WSMan provider).

When Matt and I were working on our book, I had the joys of playing with providers and figuring out how they work under the covers. I won’t scare you off from them by showing you code here – that’s in Appendix C of our book. However, if you want to get into provider development more extensively after reading our book, I recommend talking with Oisin Grehan, the coordinator of the PowerShell Script Provider project on CodePlex, which will allow you to write a custom provider in PowerShell. (Yes, a provider to create providers!)

PowerShell-Specific Providers, a Followup to 4/26

If you were sitting in my presentation last Tuesday, you may have caught my comment on some of the PowerShell-specific providers (Variable, Alias, Function) and how I haven’t really seen much use of them. While watching Allen White present on PowerShell and Policy Management in SQL 2008, I had a thought about this. I thought of a use for these providers What if you wanted to check to see if an alias existed before creating it? Same question for variables and functions…

We have the Test-Path cmdlet, so why not use Test-Path with these providers to see if the items exist before creating them?

While these are fairly primitive, they can work:

function Test-Alias($aliasname){
    return Test-Path "alias:\$aliasname"
}

function Test-Function($functionname){
    return Test-Path "function:\$functionname"
}

function Test-Variable($variablename){
    return Test-Path "variable:\$variablename"
}

Oh the random PowerShell thoughts that zip by…