In more ways than one! By Bing, I mean Microsoft’s new search engine (http://www.bing.com or http://www.bing.co.uk). I’ve been playing with it a little (and love the nice scenery pictures on the landing page). The results seem OK so far, but it seems a lot better than the old Live Search engine. And there are a lot of references to Wikipedia.
One interesting thing though, I’m starting to see referrals in my blog hits. Looking at the most recent 20 hits, 5 are from Bing.com! And if I’m seeing hits like this, then that means other folks are using Bing.
One other related bing thing, I notice that there’s already a PowerShell project on CodePlex (http://poshbing.codeplex.com). This project has created a number of Bing-related PowerShell script library. So you can do things like Get-BingSpell (to query alternative spellings for a word) or Get-BingTranslation. LIke so:
PSH [C:\foo]: Get-BingTranslation "Beer is good, free beer is better" en de
Query SourceType TranslatedTerm ----- ---------- -------------- Beer is good, free beer is better Translation Bier ist gut, freie Bier ist besser
Where are you going to be on June 19th? If you are a techie and into Microsoft technology, then perhaps you should be attending TechNet’s free Online Conference. This is an all day, free, on-line event aimed at delivering technical information that the community requested. And did I mention, unlike other events you have to pay for, this conference is free!
The conference is divided up into two tracks: Technology and IT Manager, with content to match. See the web page: TechNet Virtual Conference 2009 for more details on the agenda.
This is an excellent idea and I am definitely looking forward to hearing Richard Siddaway and Brent Johnson in particular. I’m sure glad the sessions are recorded so I can view later the sessions I missed!
Over on Tim Benninghoff blog – he has an interesting post:: PowerShell and WMI namespaces. With WMI, the classes and intances are organised under a hierarchal namespace starting at the appropriately named “root”. Individual nodes can have children which can in turn have children and so on. To some degree, namespaces are just defined by a product team and there is little consistency across software products (such is life!). But where to start?
Despite what Tim says about using the GUI, MOW’s most excellent WMI Explorer script is one fantastic tool. Not only is it a really good browser, but as Tim notes, it’s written in PowerShell which is even more cool. I use this script in most of my training courses to add value!
His post then goes on to describe two methods of obtaining the namespaces within WMI. There are two small problems with his examples. In his first example he has a minor typo – this should read as follows:
gwmi -namespace "root" -class "__Namespace" | Select Name
In Tim’s post, he spelt the class with just a single underline (“_Namespace”) not two (“__Namespace”). WMI is sadly very picky! Tim’s other method works fine and as he says produces the same output as his first (well once corrected!). On my system, this produces the following output:
PSH [C:\foo]: gwmi -namespace "root" -class "__Namespace" | Select Name
Name ---- subscription DEFAULT MicrosoftDfs CIMV2 Cli nap MicrosoftIISv2 SECURITY RSOP MicrosoftDNS WebAdministration WMI directory Policy virtualization Hardware ServiceModel MSAPPS12 Microsoft aspnet
The second point is that his two methods just produce a list of namespaces under the root. Since each node in the namespace can have children, his two methods do not list all the namespaces in which you can find classes. This, IMHO, is once case where the GUI is a better tool – visualising the hierarchy in a tree control is a whole lot easier than trying to do it from the command line. And you get the names spaces in alphabetical order (although you could do pipe the output above to Sort-Object easily enough). On my workstation I see a number of subsidiary namespaces below root as you can see here:
WMI Namespaces are a good thing to understand, since many of the classes you might want to access using Get-WMIObject (et al) rely on the –NameSpace paramater (and the appropriate namespace name!).
I’ve been carrying this book (see http://www.amazon.co.uk/Windows-Vista-XP-Professionals-Updating/dp/9072389018 to buy this book!) . It’s written by Dutch MCT superstar Raymond Comvalius. In summary, this is a great book – simple and to the point. Unlike some books, there’s very few screen shots – just lots of good straightforward text!
The book contains 8 chapters:
Chapter 1 – Introduction
Chapter 2 – What’s new in Vista and is not discused in the book – a nice touch!
Chapter 3 – Deploying Vista – a good look at the deployment tools which are all new in Vista.
Chapter 4 – Managing Vista- includes details on group policies and a look at WInRM.
Chapter 5 – Securing Vista – explains the key new security features of VIsta including UAC, file/registry virtualization and BitLocker.
Chapter 6 – Networking – Vista includes a bunch of new networking features, in effect a new TCP/IP stack, which are described in this chapter.
Chapter 7 – Mobility – a look at the mobile features of Vista.
Chapter 8 – Migration to Vista – this final chapter examines how to plan your Vista migration.
This is an excellent summary of what an IT Pro needs to know moving forward to Vista. I hope Raymond writes an update for Windows 7!
For me, the cool thing is that this is released as a module so I can import the module when I want it – or not. Nice touch. If you are using Win 7, note this beta requires Win 7 RC!
As in years past, Microsoft is hosting the 2009 Summer Scripting Games. This year, the games are co-promoted by The Microsoft Script Guys and PosCode.Org. The games will run from June 15-26 and should be a lot of fun. As happened last year, I’ve been asked to submit a sample script and am hard at work on it already!
If you are a novice, an expert, or anywhere inbetween with scripting (PowerShell or even VB Script) then visit the site, sign-up and take part.
The WMI team are now blogging in the Windows Management Infrastructure Blog. A most useful blog for those wanting to understand WMI (and BITS, and WINRM) especially those coming to this from a PowerShell point of view. One interesting post examines the WMI story, pre Windows 7 (with lots of great links to more background). Another post looks at what is coming with WMI in Windows 7 (i.e. with PowerShell V2).
This blog is well written! And any blog that can mix PowerShell, reindeers, Jedis, ands and grasshoppers can’t be all bad!
Dan Harman, a PM in the Windows PowerShell team has published an excellent blog article: Increasing visibility of cmdlet design guidelines. The article talks about cmdlet naming conventions and the importance of good naming around the verbs and nouns used in the names of cmdlets (and by implication advanced functions too). The article also talks about the problems of a proliferation of uses of PowerShell that deviate from the standards currently being set by the PowerShell team.
With the increasing adoption of PowerShell across MS and non-MS products, standards are vital and enforcement probably mandatory. PowerShell aims help organisations break down their knowledge silos. To achieve this, there needs to be a standard set of verbs and nouns you can use and some good way of enforcing it.
Microsoft proposes some changes to V2 to resolve the issue. Specifically, when you call Import-Module to import cmdlets, Powershell evaluates the module and warns against violations of the standards. The end use sees a warning message but the cmdlets are still imported. Thus, by default, when you load a module with badly named cmdlets, you get a warning message but everything works (i.e. the module is imported!). For scripts where you want to suppress the Warning, just use the –DisableNameChecking on the call to Import-Module.
This is a pretty neat solution. We’ve already seen a number of interesting approaches to the use of PowerShell by various teams, and MS is right to want to stop the problem from being a real problem.
One addition I’d like to see: a GPO setting to set a default value to enable disabling name checking. The scenario I envisage is an organisation that has, for whatever reason, invested in cmdlets that end up being badly named. Rather than have their admins constantly be reminded, or worse possibly confused, I’d like to see a GPO setting to always just not show the message for my organisation (or part of an organisation).
I’ve been posting here to this blog for a few years – and on occasion, I get a nice comment either here on the blog or in email. In September 2006, I published an article entitled Vista Shortcut keys where I described the new short cut keys you can use with Vista. Well today, I got a comment on the blog – it wasn’t much, just a short “thanks” but it sure made my day!
This is pretty cool – integration of ASP.NET and PowerShell. PowerShellASP is an ASP-like template language for Web Applications. You create templates that contain a mixture of mark-up i.e. (HTML, XML or whatever) plus inline PowerShell code. At runtime, your templates/pages are translated to PowerShell code and executed as a single unit inside a PowerShell pipeline. The results are then sent to the client browser.
As I continue to dive deeper into PowerShell WMI, I continue to be surprised by new things I discover. I’ve been playing today with the WMI Class WIN32_printer. Sometime ago, I posted a code sample over on MSDN using this class with Powershell (see the original sample here).
The original sample produced a test page on a specific printer – but I thought it would be interesting to see what happened if I ran the script against ALL the printers define on my workstation. And that got interesting.
On my system, I have two ‘real’ printers installed (a colour Inkjet and a colour laser) and two additional printers: an XPS Document Writer “printer” and a SnagIt 9 “printer”. As expected, the real printers printed their test pages just fine. But the virtual printers did not fare so well. The SnagIt printer failed to print a test page. It generated two “Unable to open message queue” error messages (in a pop-up window), then failed with a message “Unable to send a message to SnagIt” (and another pop-up). But at least it failed gracefully although the Result code was 0. Attempting to print to the XPS document writer just hung.
This result shows that, at least with WMI (and probably ALL other classes), when you start writing scripts based on base objects (i.e. WMI, COM, .NET and home grown), you need to know what you are doing. And in writing production scripts, you need to be extra careful with testing, and coding around the problem issues.
This last point is illustrated in the updated script that I published to my scripts blog: http://pshscripts.blogspot.com/2009/04/get-printertestpageps1.html. Look at lines 63-65 – these avoid calling the PrintTestPage on those printers you know to not work. This is another interesting reference to the fact that production scripting is more about “error” handling (you might call it “reality handling” too"!) than anything else. And a lot of wide testing.
As a PowerShell addict, I love sharing information about the product. I’ve just seen that Dr Tobias Weltner has finished off an e-book, entitled Master-PowerShell. This book is a free, 20-chapter work covering all aspects of PowerShell and is targeted at PowerShell Version 1. Thus, no details on Modules, remoting, etc, but nevertheless containing lots of useful information. I especially enjoyed reading Chapter 18 and learning more about PowerShell and WMI!
A very long time ago, when I was contracting for Microsoft, I got a copy of a cool internal application called Rich Copy – sort of a RoboCopy on steroids. The Internally obtained version of Rich Copy timed out after a while which was a shame.But today, I’ve just read that Rich Copy is available for download from the TechNet site: http://technet.microsoft.com/en-us/magazine/2009.04.utilityspotlight.aspx. This is a very seriously cool app – and it’s free and freely available.
I’m just back to the UK after a month on the road, topped off by a week in Redmond attending an OCS Voice Ignite Train-The-Trainer session. Last week was a week in geek heaven. We spent a lot of time exploring the inner workings of OCS. In particular, how OCS operates on the wire – both between servers and between client and server. Fascinating stuff – sheer geek bliss.
Both last week and in my Voice Ignite classes, I see huge interest around how MS has implemented SIP on the Wire within OCS. When looking at OCS wire captures, or SIP logs, you can see a huge number of Microsoft extensions to older style SIP traffic, in addition to the updates to both SDP and RTP. In preparing for my upcoming TechEd talk (SIP – Naked in all it’s Glory), understanding these better has taken on a new importance.
Whilst in Redmond, superstar VI Trainer Dennie Klama pointed me towards updates to the Microsoft Office Protocol Documents. I first came across these last summer, as noted in a blog entitled: Open Geek Goodness From Microsoft. It was cool to get access to this level of detail – although I was disappointed that the documents themselves were not open to Community Content on the MSDN site. Thus there was no way for the community to clarify or perhaps better document the details of the protocol. I’d love to see more real-world examples to illustrate the text better.
Thanks to the pointer from Dennis, I was very exited to see not only more documents than I recall seeing last July, but much more importantly, there have been updates to these documents. The most recent set of updates to the OCS related documents I’ve read so far occurred in March 2009.
Today’s news that Microsoft accepts defeat to Wikipedia and kills off Encarta, which I read in the on-line version of The Times, is quite sad. But it’s one data point in the huge shift we’re seeing from the older style printed material (and that includes CD/DVDs) to online only.
We’ve seen a number of newspapers stop publishing their print editions, and a magazine I wrote for (Server Management Magazine), I contributed for over 10 years, has also gone web only. Although Encarta was an on-line product too, the death of print media is continuing at a pretty frantic pace.
One could argue the battle was more about the content than online vs offline. For me at least, the content on Wikipedia is very good. Thinking back over the past year, when I needed information, I’ve tended to use Google and Wikipedia. In a few cases, I found Wikipedia entries wanting – so I added some content. Maybe if MS had opened Encarta up more, it’s popularity might have been higher.
As it turns out, Encarta was a very distant 2nd place to Wikipedia. With Wikipedia having 97% market share and Encara being second with 1.27% (and “print” not being significant0, the decision was only a matter of when, not whether.
I write for Server Management magazine – and over on their web site, there’s a cool offer on PowerShell Plus. For a limited time, Server Management web site readers can take advantage of the offer of $50 off PowerShell Plus, thanks to those very nice people at Idea. With this offer you can download the current version OR the latest beta from the Idera website. You don’t need not wait until the new version comes out to purchase. If you like what you see in the beta, you can purchase the current version and get a free upgrade when the beta becomes GA. Either way – it’s a good deal!
I’ve been dealing a lot lately with activation of Server 2008. It’s not been as easy as I’d like. In searching for some help, I came across a great article on SLMgr: SLMgr Commands and Options with Windows Vista Product Key Activation. This article provides a good look at the options with this SLMgr.ext tool.
This past week, I was teaching OCS Voice Ignite in Munich and a colleague (superstar Robin Edwards). During the week, we chatted about how to configure OCS’s Address Book service. This is a topic that comes up a lot in our OCS training, especially as the Address Book seems to be one of the key troubleshooting issues our delegates encounter.
As it turns out, you cannot do much with the GUI. There’s nothing there to enable you to do much more than view SOME of the settings. For example, by default, OCS ABS keeps 30 days worth of delta address books. If you login to Office Communicator, OC will download only the deltas since the last time you logged in, up to a certainly value – by default 30 days. This is a great feature for very large address books that don’t change a lot week to week.
The problem is, you can’t see this value in the GUI, nor can you set it. To view or change this, you need to use WMI in a direct way. Which leaves you three options: WBEMTest, VBS, or PowerShell. For most admins, WBEMTest is way too ugly and unfriendly and that probably is true for VBS. But PowerShell makes it very, very easy (assuming you know PowerShell of course).
DaysToKeep – specifies the number of days to keep the delta data files. The default is 30.
ExternalURL - An HTTPS URL that specifies the external location for address book file downloads
InternalURL - An HTTPS URL that specifies the internal location for address book file downloads.
MaxDeltaFileSizePercentage - The maximum percent of change for which a delta file is created. A delta file is not created if the percent of change is greater than this number. Multiply the value by 0.01 to derive the percentage. The minimum value for this property is 0 and the maximum value is 9999 (99.99%). The default value is 1250 (12.5%).
OutputLocation - Specifies the directory in which the files are stored.
PartitionOutputByOU - Controls whether data is partitioned by organization unit (OU).
RunTime - Specifies the service start time. The minimum value for this property is 0 and the maximum value is 2359. The default value is 130.
SynchronizeNow - When true, triggers the Address Book Server to perform a synchronization pass.
SynchronizePollingIntervalSecs - Specifies the number of seconds between checks for synchronization. The minimum value for this property is 5 and the maximum value is 9999.
UseNormalizationRules - Controls whether normalization is performed.
So much for what it does, now to how to do it with OCS R2. To get this class, using Standard Edition, you just use:
Get-WMIObject –Class MSFT_SipAddressbookSetting
However, using EE, it’s a bit more complex and you have to use a slightly different variation on the Get-WMIObject sytax, as follows:
PS C:\foo> gwmi -query "select * from MSFT_SipAddressBookSetting where backend='dc1'" -computer ocs-ee
Win+Space: All windows become transparent so you can see through to the desktop
Win+Up arrow: Maximize the active window
Win+Down arrow: Minimize the active window or restore the window if it's maximized
Win+Left/Right arrows: Dock the active window to each side of the monitor
Win+Shift+Left/Right arrows: If you've got dual monitors, this will move the active window to the adjacent monitor
Win+T: Shift focus to and scroll through items on the taskbar
Win+P: Adjust presentation settings for your display
Win+(+/-): Zoom in/out
Shift+Click a taskbar item: Open a new instance of that particular application
I’ve been using Win7 exclusively on my new laptop for a couple of weeks and am convinced! There are a couple of defencies, but these are driver related issues (and driver makers who do the “we do not support beta OSs” excuse. But despite that, I’m sufficiently happy with Win7 beta to not want to reboot back to XP.
I’ve often had cases with programming where I want to swap the contents of two variables. For example, suppose I have two variables $a, and $b, and what we want is to have $a contain the value of $b and $b contain the value of $a.
As an old fashioned programmer, I’d do it this way:
Now that works, but it requires the use of a third variable ($temp). If $a and/or $b were large arrays (e.g. all the file objects on a system for example) this would waste a lot of RAM and cause a GC collection.
As it turns out, with PowerShell, there’s another way:
# Assign some values $a = 1 $b = 2 # now switch $a,$b = $b, $a
In this case, PowerShell treats the two sides of the “=” as arrays and does the necessary transposition of values.
One really neat feature I discovered today is the Shft+Enter feature. If like me, you find CMD.EXE still has the occasional feature that PowerShell doesn’t quite meat (dir /s and dir /ad are two that are much harder in PowerShell), then you can enter the command and instead of hitting Enter, hit Shift+Enter and the cmd will be run by CMD.EXE. So inside PowerShell Plus, it looks like this:
PSH [C:\]: dir foo*.* /s <--- plus Shift+Enter Volume in drive C is XP_32bit Volume Serial Number is 44B8-CFED
Tobias Weltner this week announced that /n software, a provider of software components for Internet, security, and E-Business development, has become the latest sponsor for the PowerShell.Com community site. This is a great thing as it can improve the visibility, viability and hopefully the usefulness of the PowerShell.com site.
As many of you know, Orca is an MSI editor. I wrote about it a long time ago (here), but have used it ever since! I find Orca particulary useful to fix the many MSIs that stop code running on, for example Server 2003 that runs fine on XP (e.g. drivers from OEMs). Often, there’s just a line in the MSI that needs to be taken out and the MSI functions fine.
Tonight I found a neat replacement – and it’s free. Called InstEd – you can get it from the web site (http://www.instedit.com). What can I say – it does what it says. For more information, see the Online Help.
This is sort of exciting - PowerShellPlus v2.1 Beta is live! I’ve used PowerShell Plus for some time and love it. But there are things that I’d like to see, in particular the CTP3 support. Well, now we have that – and I’m downloading it as I write this post. The features in 2.1 that catch my eye are: VBS support, STA MOde, Code Sharing and of course, CTP3 support. I’ll be posting more once I have the code running and have a chance to give it a good test!
Just a heads-up that those cool Scripting Guys from Microsoft now have a on-line web forum for help on scripting. Just launched, The Official Scripting Guys Forum is a part of the overall TechNet forum and is a web-only forum (sadly no NNTP).
The forum is a one stop shop for all scripting questions, including questions on Perl, VBScript and of course PowerShell. There are a number of scripting gurus there already and I’ve agreed to be one of the moderators!
Many, many years ago, I spent a bank holiday in Amsterdam with a life friend. We had a pretty outrageous time. The highlight was seeing Dave Edmunds in the Paradiso. We had outstanding seats and the evening was magic. It was the early 1980’s and Dave was in his prime. The sound was outstanding. The environment was even better!
I was reminded of this when I came across a bootleg concert featuring Dave and The Refreshments (a Swedish band). The show features Billy Bremner. It’s so wonderful to hear tunes like “I Knew The Bride”, “Here comes the Weekend” and “Standing at the Crossroads”. It’s a real shame Debra is not on their set list. If you can find this show (it’s on a few popular torrent sites) it’s worth the download.
This was disappointing a couple of years ago, and is disappointing now. Microsoft has taken a hugely popular and well understand brand and replaced it with, well what? Replacing a credential with “Engineer” in the title with “Administrator”??? How is that an improvement?. Does MSL really expect anyone to get excited about “upgrading” an Engineer credential with an Administrator credential?
I was one of the first MCSEs in the world, and am still quite proud of that credential. I’m not sure if I could ever get 1% as excited about being an Enterprise Administrator. It just sounds a step down and backwards. As a result, I’m just not chasing the new credentials any where near as fast as I used to. I know I am not alone.
I think Bill and the rest of MSL has made a huge mistake with killing off the MCSE. The fact that he’s heard the question (“Where is the MCSE 2008”) on a daily basis indicates the market is not anywhere near enough clued up on MSLs rebranding (and like “New Coke” don’t accept it). Despite several years of trying, the MCSE is sill a better known credential than Enterprise Administrator.
I spent some time in the autumn of 2007 trying to convince MSL that they needed to invest in evangelising the new credentials, otherwise, in a year or two’s time, the new credentials would be still unknown. Two years on, MSL still hears ‘the question’ on a daily basis (or at least Bill does).
MSL made a mistake – it’s time to correct that mistake and bring back the MCSE. Learning from one’s mistakes is hard to do, but Coke did it! MSL should take a hint and do the right thing.
One of the things we chatted about was when I first saw PowerShell.I was in the back of a big hall in LA, attending PDC 2003, and watched Jim Truer and Jeffrey Snover give Monad, as it was then called, its initial airing. I got quite excited – and waved a US$20 bill in the air and proclaimed “I’ll buy it now”! Jeffrey wisely declined, but many years later (and a bit worse for wear), I finally presented the $20 to him at an event in Redmond. You can see the $20 here and here!
It was one of those events I’ll not forget – it began a passion that continues to this day. As I say on the interview, nothing that has happened since – the community, the wealth of cmdlets, etc – has been a surprise at all. About the only surprise is that it’s taken a bit longer than I’d have hoped.
If you are around and on line on Thursday evening (12:00 EST, or 17:00 UK time), check out the Windows PowerShell Virtual User Group Meeting #8. This meeting will feature June Blender from Microsoft – no doubt she’ll be talking about the PowerShell Documentation.
Go to the site to get the credentials to the Live Meeting. No idea if the session is being recorded!
I’ve long enjoyed examples of social engineering, hoping I’d never fall for them. The IRC chat, at QDB: Quote #244321, is a great example of this. Take a read (I had to read it twice!).
I’ve been working with PowerShell’s error handling – trying to get a better handle on it. Yesterday, I looked at general error handling and discussed how to trap or catch an exception. By handling errors in your scripts, you make the script more production ready. And for many, this is a great thing!
One of the problems in trapping or catching an error is knowing what to look for. You can do a blanket catch, such as:
try {
... some dodgy bit of code...
}
catch {
"code broke..."
}
At one level this works. You can catch an error and avoid your script dying – and maybe returning some interesting info. But there’s often a need to do a better job in detecting different exceptions and handling them differently. As I noted yesterday, a simple script could result in a number of discreet different errors each of which might mean different actions in your script. Along these lines (with PowerShell V2 of course):
…
try {
... some dodgy bit of code...
}
catch [... exception 1]{
"code broke due to exception 1..."
}
catch [... exception 2]{
"code broke due to exception 2..."
}
catch {
“no idea why your code broke…”
}
In this second example, you are explicitly testing for two specific exceptions as well as a more general one. The idea here is that for the first two exceptions, you might be able to find some specific information to help the caller (or you) work out what went wrong and deal with it.
The big problem is knowing what exceptions you can trap. I saw a cool script today online - PowerShell Code Repository - Get-Exception. This script looks at all the loaded assemblies and works out what possible exceptions exist and then outputs them. Makes interesting reading and is a great reference.
At last week’s UK PowerShell User Group meeting, Jeremy gave a talk on Error handling. It got me thinking about the whole business of errors and error handling in PowerShell.
One of the great differences between casual and production scripts is the need to manage, control and handle errors. If I write a script to open a file, eg c:\foo\gd.txt, I know it exists, I can see it in my folder, so why bother with error handling? Well – for casual scripting the answer is probably that you don’t need to worry. But when you start moving scripts into production, you can’t always be so sure. Stuff happens in production and your scripts need to deal with that.
There are three sets of error handling statements included in the PowerShell language:
Trap – allows you to trap any errors that occur in your code. You define the trap block before any risky code is executed. Trap is part of V1 and included in V2.
Try/Catch/Finally – these three statements allow you to try some dodgy code, catch any errors that occur in that dodgy code then do any clean up (whether or not an error occurred). Try/catch/finally is an addition to V2 and is not supported in V1.
Throw – this allows you to detect an error (for example in a subordinate script or function) and throw an error for a higher level script or function to catch or trap. This statement is in both V1 and V2.
So which do you use? It depends I suppose. For most scripts, you probably won’t need to use Throw. If you have some utility function, you might enable it to catch specific errors then throw an exception to callers of that code. Typically a throw is inside of your subordinate’s trap or catch block. You handle the error, perhaps do some clue generation (ie is the file you are trying to open, or is the drive just not accessible, etc) then throwing a more specific error. Try/catch (and finally if needed) should surround any production script logic that could fail.
There are two things that could go wrong. First, the New-WebsServiceProxy cmdlet could fail. Second, the GetQuote web service could fail. There is a third source of error ($ticker is empty), but that would be dealt with via parameter declarations, which I omitted form this snippet!
As a casual script, just showing the basics of using this web service, I don’t need to worry about such things. But if this was a web service I depended on (and is outside my direct control!), I should either have one (or possibly) to trap blocks, or two try/catch blocks. I could expand this code as follows:
return ("Can not get stock quote for {0}" -f $symbol)
}
# return results
$result.StockQuotes.Stock
}
}
This code is a bit longer, but it enables the script to run and not abort, albeit not produce the results you might have hoped for. In both catch blocks, I’ve not added much in the way of error handling. In the first catch block, some additional detection might include:
Checking the host IP configuration to see if the host is on-line and host networking is enabled. There might be a local issue with a cable being unplugged.
Checking the local IP gateway. Networking might be OK, but the gateway might be down.
Determining if the site name (www.webservicex.net) was resolving via DNS to an IP address. Networking and gateways might be OK, but the DNS resolution of the site might be down.
Checking policy to see if the site’s IP address is being blocked. You might be able to ask the firewall(s) if they’re blocking traffic to the service.
Checking For SSL/TLS protected web services – can you create the secure tunnel? Is the certificate protecting the site duff?
Pinging the site to see if it’s actually up. DNS may resolve, but the site might be down.
Opening the home page for the site to see if there’s a working web site at the root. The site might be up but the web service gone.
Etc. I suspect there are more things you could check for.
Moving on in the code, with the second catch block, you could have checked the error details to produce a more relevant exception. Simply returning an instance of $error puts the onus on the caller to handle the error. Also on both catch blocks, you could have thrown an exception for the caller to handle rather than just continuing.
As I think you can see, a pretty simple script that just creates a web proxy then calls it (effectively 2 lines of code) could end up with 10 times that many lines of error checking/handling code. This is amongst one aspect of writing production oriented PowerShell scripts.
Something related to this, of course, is the $Error variable. This is a subject worthy of an entire book chapter! I think this is partly broken – it’s hard to use for a start! But I’ll discuss this variable and why I think it’s broken in another blog post.
Every year, like many of you, I submit proposals for TechEd. In recent years, they’ve been less than successful – the competition is very fierce and there is so much great content to choose from. I almost have to feel sorry for the Microsoft folks having to wade through hundreds of proposals.
This year, I submitted three talks, two around PowerShell and one around OCS. To my great surprise and delight, one has thus far been accepted! YEAH
The accepted break out sessions, part of the Unified Communications track, is entitled “SIP - Naked In All Its Glory”. The abstract for the talk is:
This session will look at the key protocols behind Microsoft's OCS product, in particular Session Initiaion Protocol as well as Real Time Transfer Protocol (RTP) and Session Description Protocol. A short discussion on TCP, TLS, and PSOM will also be given. The talk will focus on looking at the SIP and related protocols "on the wire". We'll dive in to using NetMon as well as OCS's Snooper tool. Troubleshooting SIP will be the final part of this talk.
I’m still waiting on the other two talk proposals. The other proposed talks are PowerShell related and are titled: “PowerShell and WMI”, and “Writing Production Quality Power Shell Scripts with PowerShell V2 and Windows Serer 2008 R2”. I await the verdict on those two talks, but would like to think that at least one will get accepted
Irrespective of the PowerShell talks, I’m really excited that I’ll be a speaker again. LA, here I come!
Posts
