If you are interested in PowerShell and are on Twitter, I’ve compiled a (continuously expanding) list of Twitterers who often have PowerShell related content.

To make it a bit easier, I’ve written a script that will parse that list, compare it to whom you currently follow, and follow anyone you are missing.

The script (Add-PoShTwitterFriend) can be found here.

The list of PowerShell Twitterers can be found here.   If you are into PowerShell and on Twitter but not on the list, let me know (@stevenmurawski), I know I’m missing some people.

UPDATED…. Thanks to a tip from Jeffery Hicks, I updated the Add-PoshTwitterFriend script so it should run more smoothly

I’m often asked why I like PowerShell so much. There are a number of reasons, but what I find most compelling about PowerShell is that it is an enabling technology.  With PowerShell, I am in charge of my admin might.  There is nowhere my shell cannot reach…  (ok.. maybe I’ve watched a few too many Conan movies).  The point is that I don’t have to rely on an outside party to customize their management experience to my environment.

With applications that support PowerShell, my general Active Directory environment, and those applications and datastores that can be coerced into working with PowerShell, PowerShell provides me a way to create the management tools that I need, specific to my environment.

• My custom .NET based application with a SQL backend doesn’t keep user information syncronized with my Active Directory.. No problem, schedule a PowerShell script to run and verify the information.
• Want to take a look at the door access control system users and find the users whose Active Directory accounts are disabled? Not a problem for PowerShell.
• Have fifty new user accounts that need to be added to both those applications and Active Directory and need mailboxes enabled? PowerShell to the rescue.
• Need to retrieve a photo that is stored as a BLOB in a database and save it to your local filesystem. Easy, with a bit of PowerShell.
• Want to read through an XML Configuration file, find a few elements and verify them against machine settings or other configurations? Can do! XML is a breeze to work with in PowerShell.

PowerShell allows me to create and define my own administrative tasks through the creation of scripts, functions, and cmdlets, which empowers me as an administrator to get my job done in as efficient a manner as possible.  I can also modularize my tasks (which makes them easier to share).  By isolating the tasks into reusable bits of PowerShell, I can quickly respond to a changing environment, creating custom workflows as needed.

If I’m having trouble with my task, I can turn to the PowerShell chat room on irc.freenode.net, ask a question in the forums at PowerShellCommunity.Org, or turn to one of the numerous books, blog entries, or script samples from PoShCode.org for inspiration.

Then, once I’ve solved a problem, I can share the solution with others via a community site like PoShCode.org.

I was writing a quick script to get the Group Policy Health status (using the free Get-SDMGPHealth cmdlet from SDM Software) from computers in various OU’s in my domain.

One option for output from the Get-SDMGPHealth cmdlet is as an XML Document, which is a type of object.  One of the methods (actions an object can take) on the XML Document is the Save() method.  The Save() method does exactly what it says.. it saves the XML Document object as an XML file.

I was using the PowerShell Plus script editor and the interactive console showed my working directory as “C:\documents and settings\myaccount\”.  I ran the script and did a directory listing (I was saving the output with a file name of  “computer name”.xml), but did not see any output.  I ran it again and again, but nothing was writing to the current directory.

I remembered a post that Joel “Jaykul” Bennet wrote about the “Current Directory” problem in PowerShell.  Joel posts an interesting explanation of this issue, as well as a great solution to this problem by modifying the PowerShell prompt function. 

Scenarios where this issue can be a problem is when you are providing a relative path to a .NET method call (which will resolve the full path by using what it sees the Current Directory as).  If you want to avoid all of this, you could pass in full paths (the Resolve-Path cmdlet comes to mind).

Now, you will know where you are!

On tomorrow’s live show, we will be joined Richard Campbell, host of Runas Radio and .NET Rocks.  Richard will be joining us to talk about keeping up on new technology, working with developers, and I’ll try to work some PowerShell content in as well!

Join us in the live stream tomorrow night (Wednesday, December 17th) at 8:30 PM CST!

Recently, I posted a script that would map out various Active Directory objects using Doug Finke’s Show-Netmap script and the .NetMap research project from Microsoft.

Doug Finke was recently a featured guest on the Powerscripting Podcast and was talking about using .NetMap with PowerShell.  I was able to be in the Ustream audience during that show and asked if Doug was aware of what was happening with the .NetMap project, since the Codeplex project was unavailable.  One possible explanation was that a developer had left Microsoft and perhaps there were some intellectual property issues.

Well, I found out some of what happened.  One of the developers did, indeed, leave Microsoft to join Telligent, but the project has resurfaced under the name NodeXL.  All of the goodness that was .NetMap is now NodeXL and available on Codeplex.

I’ve modified the Show-Netmap script to Show-NodeXLMap, and updated the Get-ADMapObject script to the Show-ADObject script.  Both the Show-NodeXLMap and Show-ADObject scripts now support adding color to the maps.

Examples:

./Show-ADObject -ShowADClasses #Lists out all the available Classes or types you can map out

./Show-ADObject -ADClass group, organizationalunit, contact -Colorize #Maps out the groups, contacts, and OU’s.  Groups will have one color, contacts a second color and OU’s a third.  The color key will print out to the console.

./Show-ADObject group, organizationalunit, contact -MapLayout Grid

I’ll be updating and re-posting my Group Association script to support the new NodeXL project and colored objects.

You can download all the necessary files (except the Quest AD Cmdlets) here.

If you are interested in this type of network mapping, check out Doug’s other examples.

After being challenged by Jason on my previous script, I created the Get-ADMapObject script.

Running the script creates three functions:

• Get-ADMapObject (which takes a string or array of strings of the AD object classes)
• Get-ADObjectClassName (recurses through your Active Directory and returns the names of the object classes)
• New-SourceTarget (to get the ADMapObjects into the format that Show-Netmap wants).

Before the script runs, it will check for the dependencies (Doug’s script and the NetMap dll’s) and advise you if there are any missing. I’d love some feedback!

download | copy to clipboard | new post

We will be streaming live tonight on Ustream.TV at 8:30 CST/9:30 EST.  Join us in the chat room along with the streaming audio (and some video)!

Andy Schneider (of the Get-PowerShell Blog) just posted a great blog post about a topic that is often overlooked, but can be a great source of frustration and conflict in the workplace.

This is a question that goes un-asked and un-answered all too often. So often I am in a meeting where Project Manager X asks Engineer Y, “Can you do so and so?” and the engineer says “Absolutely!” and we move on to the next item on the agenda. This is a recipe for disaster. There is no set time that this task is due. There is no promise or commitment.

One of the bigest hurdles I run across in my day job is pinning people down on when they expect certain work items to be done.  The most common response is “When you have time…” or “It’s not a priority…”.  To me, that communicates that the task is not time sensitive and can be put into the pile with the other requests/problems I have to look into.  Currently I have about 80 active items that need some sort of action in my ticketing system, plus the daily requests and fires that come up during the day.  It could be weeks or months before something with a low priority gets action (it is reviewed every week as part of my weekly review).  The requestor, though, might believe that a low priority item should be done by the end of the day or end of the week.  It becomes necessary for me to force the requestor to give me a date as to when their item is needed by; and if I don’t, it can lead to frustration on the part of the requestor and exasperation on my side, when their “low priority” item becomes a fire that needs to be put out.By the project manager not defining when the task is expected to be done and the engineer not commiting to a timeframe, the stage is set for conflict and slipped schedules.I’ve become a fan of agile practices which are growing in popularity in software development cycles, but can be applied to systems and network administration.  These practices encourage frequent communication and status updates, as well as responding quickly to changes in requirements.  None of this is possible if everyone is not clear on what is expected to be done by when.  Communication is the foundation of a smooth running process and “By when?” is a critical component of that communication. Expectations and ability to complete the task by that expected time need to become a required part of any task assignment, and both parties need to use the same, specific terminology and keep the lines of communication open if the schedule changes or the time needed to complete the task changes.

PowerShell interest seems to be flooding all sorts of Microsoft product communities.  Now on PowerShellCommunity.org, there are forums specifically for SharePoint and SQL Server.  Check them out! 

If you have PowerShell related questions, suggestions, or solutions, please stop in and post!

See you there!

We will be streaming episode #77 live on Ustream.tv on Wednesday, November 26th at 8:30 PM CST.  We will have Brent Ozar, SQL Server Expert for Quest Software, joining us to talk about becoming a DBA (Database Administrator), a sysadmin’s guide to working with DBA’s, and tips for sysadmins who have become “Accidental DBA’s”.  We’ll also have a discussion about DBA’s and scripting, and some news from the PASS (The Professional Assoication for SQL Server) Summit.

 See you there!!