One of the things I really love about Powershell is the Secure Credential object, or PSCredential object. I even wrote about using it here and here. But a recent script request over at Spiceworks has shed some light on the PSCredential and now I’m not so sure I like it anymore! Read on.
The other day Richard Hipkin over at Spiceworks requested a custom version of the Employee Directory that I blogged about last week. The irony, and isn’t this always the case, is that he wanted something I had removed from the original vbScript that had been there! Richard wanted to add Location as well as the employee’s manager into the mix. Normally this would have been pretty simple and I would have just sent it over to him without comment but I ran into an interesting problem that I wanted to write about here.
Found a user on Spiceworks who was struggling getting vbScript to send an email using SMTP authentication. While very possible to do in vbScript (Paul Sadowski great blog I’ve used for years) this is definitely one of those things where the code just looks ugly and it can be a little confusing. Powershell’s Send-MailMessage cmdlet takes all of that away. Combine that with the RSAT tools for Active Directory and you can do some pretty cool things very easily. So read on to see how I solved this problem.
Part two of my talk about converting my Employee Directory with Photo’s vbScript into Powershell. Part one here.
But I’m all about Powershell now, and it was time for a re-write!
I’ve decided to slow down the posting a bit as I was going a bit crazy there! The plan, assuming I can stick to it, is to post every Monday and Thursday. Assuming, of course, that I have things I want to talk about. It’s been fun writing about the little projects I’ve been working on, and really helped me understand better what I’m doing. I’ve even spotted problems with my scripts as I break them down and run through it.
As with most plans, of course, I’m breaking the Monday/Thursday rule on week #1 with this post. But I think I’ll make Friday’s more about random things I’m thinking about that aren’t necessarily Powershell or IT Admin based–but almost certainly tech based! I am who I am!
A little while back the Microsoft Scripting Guy, Ed Wilson, blogged about creating a simple web page with server uptime. It was an interesting use of some of the Powershell capabilities and the output was pretty good, if a little uninspiring–not his fault I might add, more a limitation of the Powershell tools he was trying to use. I didn’t do anything about the script at the time, but it always intrigued me. Then the other day a very similar request came across on Spiceworks. At first I just gave the guy the same link I put above, but now the bug was in my ear and I decided to write something up.
I read somewhere that Powershell was built for reliability, not for performance and that’s really true. I ran into this a lot on the DFS Monitor project, where running queries against 40,000 records in memory were taking 1.2 seconds or so. But there are a few things we can do to improve performance if needed. The simple fact is most chores you’ll be doing with Powershell will not run against these performance limitations and you’ll be more then happy with your scripts.
But an interesting thread on Spiceworks came up and really gave me the opportunity to test some things, and I thought I’d talk about it here.
As I have delved into Powershell more and more, I’ve noticed that a lot of the Microsoft cmdlet’s require the use of FQDN’s and finding that full name isn’t as easy as it really should be. Typically I have to go into ADSI Edit, drill down the Active Directory tree and then go into the properties of the object I want and locate the cn property. The FQDN I find myself needing most often is for my Organization Units (OU’s). Here’s a little function I created to help me find that information quickly and painlessly–it even puts the information into the clipboard so you can paste it into your script with ease. Read on, fearless readerer!