For last week’s Friday Fun, I posted a PowerShell script to create a traditional Bingo card. I hoped you would also learn a few PowerShell concepts along the way. This week I’ve taken this to the next level, and have a complete module that not only creates the card but also let’s you play the game. There’s a lot going on here with regular expressions, custom view PS1XML files, variable scope and more. Continue reading
My weekly column that I’ve been writing for MCPMag.com is now officially Prof. PowerShell. The column’s goal is to introduce you to PowerShell and help you get up to speed. I obviously can’t teach you everything in a weekly 300 word column, but hopefully it will be enough to get you going and if nothing else, keep PowerShell on your radar. You’re going to have to eventually learn PowerShell so avoid the rush and start now. This week’s column introduces you to the Get-Member cmdlet.
You can also find PowerShell tips in some of last Windows Tip Sheet columns.
I hope you’ll let me know what you think. You can read Prof. PowerShell at http://mcpmag.com/columns/columnist.asp?columnistsid=81 or add the site’s RSS feed. I believe you can also get the column via weekly newsletter as well if you prefer.
If you want even more PowerShell goodness, I’d also suggest getting the Windows Administration in RealTime ejournal from RealTimePublishers.com. I write the Practical PowerShell column which solves a real-world problem with PowerShell. I think you’ll like it.
Late last year I had moved my PowerShell blogging to PowerShellCommunity.org. However, decisions have been made to discontinue the blog module. Now, all my PowerShell related blogging will be back at blog.sapien.com. Hopefully you already have it in your RSS feed. You can click on the Powershell category to see all related posts from not only me but also Don Jones.
On a related note, keep an eye on my Windows Tip Sheet column. You should start seeing more and more PowerShell in the next few weeks.
This week’s Windows Tip Sheet column is about opening an Explorer window from the command prompt. One of my readers sent me an email about using this tip in Vista:
I’m currently running Vista and when I type “explorer.exe /e, %cd%” I get the same results as “explorer.exe /e /root, %cd%”. So is /root really necessary? Wouldn’t it be faster to remove it if you get the same results?
He’s right in that you essentially end up with an Explorer window opened to the current directory. But there is a subtle difference that might matter to you. When you use /root, you should see that folder tree in the left hand pane is “rooted” to the specified folder. When you do it without /root, the folder tree is the full tree showing your computer, network places and the rest.
On my Vista Ultimate laptop, I didn’t really notice any performance difference between using /root or not. It would save you from typing a bit, but I use a batch file anyway.
It boils down to how you intend to use the Explorer window. If you want to easily navigate away from the current folder, then don’t use /root. The command is flexible so do what works for you.
In my current Windows Tip Sheet column on the popular freeware program nLite, reader Tim from Michigan makes an excellent observation:
Have used both nLite and vLite and agree both are excellent tools and have real value. My concern however is what else is the program doing? The program is free and having built multiple iso files with custom configurations it appears to do exactly what it says it’s doing. But what’s it doing behind the scenes that I don’t see? Is it installing rootkits, backdoors or other exploits that will make my production network vulnerable for future attacks? I haven’t found any issues, but how can I be sure? If I can’t be sure how can I justify using it in a production environment? Don’t get me wrong, I still use the program, I just use the iso files in my test environment and on virtual machines that won’t go into the production environment. I’d love to have the question addressed and some assurance that nothing else is being done.
I whole-heartedly agree. Tim is practicing exactly what I would initially recommend which is to test anything and everything in a non-production environment. This should apply not only to freeware products like nLite but Microsoft products as well. Malware aside how do you know the latest gee-whiz reputable vendor solution won’t break something? But that goes beyond Tim’s point.
Let’s talk about nLite. How can we be sure it really isn’t doing anything under the hood? Well first, I think this particular product has an established track record with a large install base. You would think that any problems would have surfaced by now. I’m not aware of any with nLite. By the way, let me be clear that I’m only using nLite as an example for the sake of discussion. As far as I can tell it is an excellent piece of software.
But let’s assume there might be more to the story. In that case I might look to tools like FileMon and RegMon from Sysinternals to monitor the install process. I’d certainly make sure I have up to date antivirus and antispyware products installed from reputable vendors. I might run the free rootkit detector, also from Sysinternals. There are others as well.
I might also consider using an application packager, like Wininstall LE because it’s free, and see what changes the app makes to my system.
What steps do you take to ensure something you are installing is safe?