Archive for May, 2008

Changing AD permissions

I’ve recently blogged about retrieving AD security with PowerShell, as you can probably guess for every Get-* there is a Set-* and AD cmdlets 1.1 provide you an easy way to change the permissions set on any AD object.

Add-QADPermission and Remove-QADPermission are your biggest friends here.

Well, obviously and the power of the PowerShell pipeline. My favorite example is copying permissions from one object to another with that simple oneliner:

Get-QADPermission “Dmitry Sotnikov” | Add-QADPermission “Evil Tween”

This simple line is incredibly powerful. It takes all permissions directly set on the first objects and adds them onto the second one. Of course you could put where in the middle to do some filtering if you need.

Of course you can explicitly grant specific rights on specific objects. Suppose you want to give Administrator full control over an OU and everything in it. Easy:

Add-QADPermission OU=Demo,DC=mydomain,DC=local -Account Administrator -Rights GenericAll

You can use the -Deny parameter to deny access, -PropertySet to work with property sets 🙂 and -ApplyTo to select whether you want to give rights only to this object or its children or any possible combination. So for example you could do:

Add-QADPermission dirObjectIdentity -Deny -Account trusteeIdentity -Rights WriteProperty -PropertySet (General-Information,Web-Information) -Property samAccountName -ApplyTo ThisObjectOnly

You can also pipe any AD object into these cmdlets (similar to reading the objects) for bulk operations:

Get-QADUser -City Orlando -SecurityMask Dacl | Add-QADPermission -Account Dmitry Sotnikov -Rights ReadProperty

And, as you can easily guess Remove-QADPermission can delete any ACE in much the same way. For example, let’s remove all the Deny ACEs from a particular object:

Get-QADPermission objectIdentity -Deny | Remove-QADPermission

You can find more information and examples in the user’s guide and by typing get-help for any of these cmdlets.

Download the cmdlets and give us your feedback at the AD PowerShell discussion forums.

Tags: , , , , , , , ,

Monitor web-site availability

Did you know that you can use PowerShell to monitor your website and send you alarms when something goes wrong? We had availability issues with our community site and I was quite surprised that the 20-line (!) PowerShell script did the job!

Basically, all I had to do was use the Net.WebClient object and its DownloadString method to query the page (with some proxy handling code I got from Alexey Chuikov), and trap any exception which it generates when something goes wrong. The trap is using our internal relay server to send me and everyone who is involved in the site administration the email.

Here’s the code:

# Test-Site - script to test web site availability
# and notify in case of any issues
# (c) Dmitry Sotnikov

function Test-Site {
        "Failed. Details: $($_.Exception)"
        $emailFrom = ""
        # Use commas for multiple addresses
        $emailTo = ","
        $subject = " down"
        $body = "PowerGUI web site is down. Details: $($_.Exception)"
        $smtpServer = ""
        $smtp = new-object Net.Mail.SmtpClient($smtpServer)
        $smtp.Send($emailFrom, $emailTo, $subject, $body)    
        exit 1
    $webclient = New-Object Net.WebClient
    # The next 5 lines are required if your network has a proxy server
    $webclient.Credentials = [System.Net.CredentialCache]::DefaultCredentials
    if($webclient.Proxy -ne $null)     {
        $webclient.Proxy.Credentials = `
    # This is the main call
    $webclient.DownloadString($URL) | Out-Null

Test-Site ""

To test it you can obviously just put an invalid URL into the call.

Once I had the script running, I just set up a scheduled task in Windows Task Scheduler to run the script every 15 minutes:
Windows Task Scheduler with a PowerShell task

One trick I learned from MoW and used in the task, was using the -command parameter (rather than just supplying the script) and including the exit $LASTEXITCODE into the command, so the exit code from the PowerShell script gets registered as the scheduled task result.

So here’s the command-line I have scheduled:

c:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -Noninteractive -command ". c:\scripts\test-site.ps1; exit $LASTEXITCODE"

Works flawlessly! And can save you tons of money on a monitoring solution. Talk about ROI from learning PowerShell! 😉

Tags: , , , , , , , ,

Changing PowerGUI UI Language

As I mentioned yesterday, thanks to the community efforts PowerGUI is now available in 7 different languages and the list keeps growing.

If your language is among the ones available for download:

  1. Simply download and install PowerGUI,
  2. Download the localization pack,
  3. Extract the locale folder to the PowerGUI installation folder:

PowerGUI installation folder with localization packs

If your Windows language is that same language you have installed, just restarting PowerGUI will do the trick – it will change the UI language automatically.

If your Windows language is different (e.g. Windows UI is English, but you want Danish PowerGUI), you will need a couple of extra steps:

  1. Go to the PowerGUI profile folder:
    C:\Users\username\AppData\Local\Quest Software\PowerGUIon Windows Vista and 2008.
    C:\Documents and Settings\username\Local Settings\Application Data\Quest Software\PowerGUIon Windows XP and 2003.
  2. Open the quest.powergui.xml file in Notepad, and change en-US to the name of your locale (which is the same as the localization folder name):

Manually setting PowerGUI language

That’s it! Now you will have PowerGUI speak your mother tongue!

Tags: , , , ,

PowerGUI in Danish

Thanks to Kevin Steffer, PowerGUI is now also available in Danish!

PowerGUI admin console and PowerShell scripting IDE in Danish

As far as I remember despite fantastic command of English, prince Hamlet was not really using PowerShell a lot. I hope that now that we have PowerGUI in Danish this last obstacle which some of his fellow citizens had is gone!

PowerGUI is now available in 7 languages – all of which can be found on the downloads page.

Tags: , ,

IIS 7 PowerShell Rant

I spent last week playing around with IIS 7 PowerShell provider (and cmdlets) and feel like it’s time to share my experience and provide feedback to the IIS team.

Overall my experience was pretty bad. I found the provider and cmdlets not really making administration any easier, being hard to understand and use, error prone and sometimes even dangerous. The PowerShell provider is currently Technology Preview 1, so I hope my feedback is timely and things can still be changed.

In a nutshell, similar to SQL, IIS 7 PowerShell provider has the provider: exposing sites and application pools – and 16 cmdlets.

I am not sure what is the value of the provider because the structure of the namespace is actually not dynamic (like for example AD or file system) but fixed to this hierarchy:

                Site Collection
                       Applications and Virtual Directories

In my opinion, in that case, provider has no real value, because cd iis:\\sites is not any easier than get-site. Actually it is worse, because get-site could have additional parameters for filtering like for example get-site -running -author Dmitry.

Working with object properties is even more painful. Just getting them is a weird process of traversing an unknown XML structure. For example, let’s say you would like to know which ports are your site listening, or various connection limits, or log file information – these are all hidden as elements of child collections inside the objects.

You cannot use: get-site | format-table Name, Port, *limit*.

Instead you have to use something like:
$site = get-item SiteName

Getting this into a table for multiple sites is sure possible using the ability of format-table to accept custom columns with expression – but that’s not the syntax I find myself comfortable to use.

However, that is nothing compared to trying to change any settings. For my demo I wanted to change all my sites with int* prefix currently listening to port 80 to use 8080 instead. Well, first of all I had to just use dir int* because adding filtering by bindings would have made my code too hard to follow for the demo, but then I had to do something like:

dir int* | Set-ItemProperty -Name bindings -Value @{protocol="http"; bindingInformation="8080"}

Not only typing this is a pain (why not have: Set-Binding -Protocol Http -Port 8080 ?) the code actually damaged my lab because it turned out that the sites also had custom URLs they were using and these got deleted, so the sites got assigned to localsystem and were stopped due to a conflict.

Because most of the properties are organized that way – as various property hash tables and hierarchical structures – changing anything is a pain.

And these are basic scenarios. Even creating a site requires you to use this awful hash-table syntax:

PS IIS:\Sites> New-Item iis:\Sites\TestSite -bindings @{protocol="http";bindingInformation=":80:TestSite"} -physicalPath c:\test

Changing any configuration properties again requires you to use some weird filter path specifying how to get to that property. Can someone really type this?

PS IIS:\Sites\DemoSite\DemoApp> Set-WebConfigurationProperty -filter /system.webServer/security/authentication/windowsAuthentication -name enabled -value true

Bulk operation require using XPaths and are completely beyond my comprehension:

PS IIS:\Sites\DemoSite\DemoApp> set-webconfiguration "/system.webServer/handlers/add[@path='*.aspx']/@path" -value "*.mspx"

I am not a web admin – so there is a chance that I am just wrong in my assumptions, and all the examples above are absolutely intuitive for any web guy. However, I find them all magnitudes more complex than Exchange or AD cmdlets, and I have a suspicion that for some reason the IIS team simply decided not to spend time looking at these examples or documenting the use case and designing for them, but instead simply looked for the easiest way to expose their xml config files via PowerShell.

To me the goal of PowerShell is making IT automation easy. And to me this does not look easy at all. In fact I think all these @{} scared a lot of folks watching my demo at the ReMIX last Friday.

In the documentation, Thomas Deml is saying that the reason for this hash-table approach is that IIS configuration is flexible and fully extensible. I am not sure this is an excuse. AD is also extensible and its objects can have any elements you add when extending the schema. However, there are ways to handle that. For example for AD cmdlets, we are exposing all frequently used and standard elements as properties and cmdlet parameters and have additional parameters such as -ObjectAttributes for those extended ones.

I really hope that it is not too late to redesign the IIS snapin with real use cases in mind and make it more Exchange/AD/DPM-like. Thomas does mention a couple of times that they “are thinking about wrapping some typical tasks like creating sites with additional functions or scripts in a later Tech Preview.” however, I am afraid that just adding a few scripts will not solve the issue – scripts are second-class citizens compared to cmdlets and just adding a few of them will not solve the overall complexity problem.

Guys, please re-use the expertise from other teams. Talk to Vivek Sharma or Evan Dodds, talk to the PowerShell team, or PowerShell community folks (like QAD cmdlets guys). Many people have been on similar tasks before and will be happy to share their experience.

On the positive side, Thomas has actually done a fantastic job documenting the current state of the provider in his series of step-by-step tutorials at – I highly recommend these walkthoughs if you want to get started.

The current status of the snapin is Technical Preview, so hopefully this all is out to collect our feedback and I hope others chime in and give the IIS team good feedback from their side. IIS 7 is overall a great step forward compared to IIS 6. The team is clearly listening to community feedback so let us be vocal here as well.

Tags: ,

PowerGUI 1.5 RTMs

We have just shipped PowerGUI 1.5.0 – which is a very important upgrade for us with a lot of new and exciting features.

Right now I am overexcited to provide a detailed what’s new list so I will just give you the ones off the top of my head and will hope that others (or myself later this week) will provide a more detailed overview.

PowerGUI Administrative Console:

  • New filters: we have completely revamped the set of filter operations to make them much more user-friendly so you get “starts with”, “ends with” and so one instead of “like”
  • Totally revamped code generation for the PowerShell Code tab. We got rid of scriptblocks and made the code much more readable.

PowerGUI Script Editor:

  • Output window now has a live PowerShell prompt built into it!
  • Multitab UI.
  • Edit menu has options to copy code as HTML or RTF – for all bloggers out there.
  • Errors are written to the output window (obviously in red).

Both components:

  • Both x64 and x86 version installed on x64 machines.
  • A much nicer input box is displayed for your read-host commands.
  • Ability to manually change the UI language.

And multiple smaller improvements everywhere!

Now we will probably get back to smaller regular 1.5.x upgrades getting you even more exciting features in the next few months. There’s so much on our roadmap that this is going to be a very exciting year for the PowerGUI team and user community. Please visit our discussion forums and let us know what you think and what you want to be added to the product.

You can download this latest version as well as updated localization modules from

Tags: , , ,

TFS inside PowerGUI

Steve Crouse has recently published his PowerGUI pack for Microsoft Visual Studio Team Foundation Server – thus, fulfilling James Manning’s long time wish. 😉

This is a very nice tool allowing for browsing the work items for all the projects on a Team Foundation Server either by area or iteration. In addition you can view all open work items assigned to you, regardless of project. Project metadata such as the work item editing form definitions can be viewed for each project.

PowerShell-based PowerGUI console for Visual Studio Team Foundation Services

The default work item edit form can be launched for work items (although until PowerShell 2.0 is released with support for execution under Single-threaded Apartment mode the form does not function correctly.)

And, as usual the PowerShell code tab lets you easily see how everything you do translates into PowerShell – so you can later use this knowledge to automate things in your project (Steve basically loads the Team Explorer assemblies and uses them to connect to the server and retrieve data.)

You can download the VSTFS pack and leave your comments and feedback to Steve.

Tags: , , , , ,

My Recent Tweets


The posts on this blog are provided “as is” with no warranties and confer no rights. The opinions expressed on this site are mine and mine alone, and do not necessarily represent those of my employer - WSO2 or anyone else for that matter. All trademarks acknowledged.

© 2007-2014 Dmitry Sotnikov

May 2008
« Apr   Jun »

%d bloggers like this: