I wanted to write a script to change some drive volumes around for a new partitioning scheme. Being me I wanted to do it in PowerShell, so I searched Google, Live, etc. to find a quick answer and ... found nothing. Not a single person with a post on how to change a drive letter with PowerShell. Maybe it is considered so easy no one has ever bothered blogging about it? This needs to be corrected though, I believe, and so I shall.
Grab the Win32_Volume WMI object and filter the results so you only get the drive letter you want. In my example I use E:.
Next up we enter an overly complex command to change the drive letter. In this case to D:.
$volume.DriveLetter = "D:"
And finally we save the changes with a put().
$volume.put()
Seriously, that's it. And now for some random notes taken from my experimentation...
Use $_.Label if you don't know the drive letter, but know the volume name (like OS, Data, Vista, Local Disk, etc.).
If you want to remove the drive letter, use this command: $volume.DriveLetter = $null (you still need the put()).
Mounting the volume to a folder goes like this: $volume.AddMountPoint("C:\path") Be sure the directory exists first. new-item can be used to make one, and test-path can be used to check if it's there.
On a lighter note, I built a second system last weekend and work got me a KVM so I could switch between my work laptop and my new test system. It's a StarTech.com SV211KDVI. It can control two computers using DVI and USB for both mouse and keyboard. It also has a nice feature where you can switch between computers using a keyboard shortcut.
I panicked today while I was using it because it kept switching between computers without me pressing the button or using the keyboard shortcut. I was about to bust out a bucket of KFC as an offering to the tech deities when I figured out my possession problem. It turns out the switching happened every time I clicked into a VMware Infrastructure Client (VIC) console window. Not the one inside the VIC, which works fine, just a breakout console window. How random is that? VMware Tools apparently uses the some keyboard code that is identical to the one StarTech uses to switch computers. Freaky stuff.
Yes, in February of 2004 I was trying to help people understand and appreciate the benefit of cloud hosting. I didn't have the marketing powerhouse of Microsoft or Google, nor was the term "cloud" being used in the industry, but the technology was available and at ORCS Web we had already been supporting clients of various sizes on cloud platforms with great success.
I continue to be a huge fan of cloud hosting and believe it deserves consideration from anyone who takes their web application hosting seriously. Success on the platform takes a lot more than just throwing a few servers online though so clients should be looking for a host with years of experience and proven successes. There is also more to hosting than just the infrastructure. Strong technical support and excellence in customer service are also key to successful hosting solutions so clients should read reviews and check references before entering into a hosting relationship.
We'd love to help your web solutions be successful so let us know if you have any questions or if there is anything we can do for you.
One of the best features in PowerShell (PS) is functions.I can’t make that any clearer.Before diving into PowerShell I was a command prompt (CMD) geek who was scared to death of that horrible alien looking VBscript code – vbscript still does frighten me a little.This is why I was happy to learn that PowerShell held on to its CMD roots, and that was the driving factor in getting me to start learning PowerShell.
Being more of a scripter than a coder, though, I initially refused to work with all that object-oriented craziness and kept to my simple CMD logic.While I was pleased to see that working with variables was much easier than with CMD, I was disappointed to see such tight execution policy restrictions.I understand why, I just don’t like it.Overall I was happy enough with my simple PS ways to finally, after a decade, abandoned batch files.Then I started working on the System Information script and all that changed.
Suddenly I had to add in unfamiliar logic operations, loops and *gasp* object-oriented code.On top of that I had to make the output look aesthetically pleasing using HTML code which had to be uploaded to a SharePoint site.This meant that not only was I learning new PowerShell code and techniques, but I was also using PowerShell to dynamically generate code for a completely different programming language!Here’s the fun part, it took me a week’s worth of spare time to do it.
Enough of the chit-chat, time to get into the script itself.We’ll start with the main body of the program itself.
For those who have never programmed with functions and objects before, welcome to a new world of programming logic.I do only three things with the “code body”: document (the only thing that stuck with me from my programming classes in college), call two assemblies, and then call the first function.The rest of my code is held inside of said functions.
One thing I learned, and I’m sure all you seasoned programmers out there will laugh when I say this, is that you should always put your functions first.If you put the program body before the functions you get a nasty little error and nothing works.
Now let’s take a look at startGUI to see how I really kick things off.
When PowerShell 2.0 comes out we PowerShellers will be able to use the Windows Presentation Foundation (WPF) to make some pretty slick interfaces, until then we are stuck with Windows Forms.Not as pretty, but still functional.Incidentally, those two assemblies called in the main program body are for the GUI.I call them in the program body instead of the function itself so I only have to call them once and not each time I run the function.
You can actually run this code directly from the PowerShell command line window by copy/pasting the two assembly calls then the guts of the function, minus the last line – which calls the next function in the program.
This is a very simple UI that asks for a hostname or IP.You have two selection options, OK and Cancel, which can be triggered by either clicking the buttons or using Enter/Escape on the keyboard.The form body consists of a text box, where the user can enter information, and a label for the text box.I would love to say that I came up with this all my lonesome, but since this is slightly modified code ripped straight from one of Microsoft’s “Windows PowerShell Tip of the Week” posts I won’t.Instead I’m going impart you with a two links that I have found invaluable when creating Windows Forms from PowerShell, and then let the experts tell you how it all works.
The second link is especially handy when you decide to build more complex interfaces.For example, one of the latest interfaces I built is nearly 200-lines and uses labels, textboxes, checkboxes and a dynamically populated listbox.All of which I figured out by understanding the code from the PowerShell tip above and by reading about the forms namespace.
Before I close this blog post out I will impart a few bits of UI wisdom I have learned.First, document well.Well documented UI elements, and code for that matter, make it easier for you to recall and reuse code.Second, keep your code neat.You don’t have to follow my format, but the cleaner you keep your code the easier it is to recall and reuse it.Notice the pattern yet?Third, there is no miracle way to easily make a UI.Create a second script separate from the one you are building specifically for generating the UI so you can tweak it easily and quickly.It will take time and patience to get everything lined up properly.And lastly, Windows forms work differently on different systems.I hate saying this, but a form that looks perfect on my Vista laptop may look horrible on a 2003 server.Either build some test VMs or find some systems to test your UI on so you can find the best common settings for all.
Hopefully the WPF support in PowerShell 2.0 will fix a lot of the UI woes in PowerShell 1.0.I haven’t had time to dig into WPF support, but if you are interested there is a great series of articles about it starting here:
I've noticed that a few hosting companies are now advertising that they have "dedicated cloud" solutions. That's an interesting bit of marketing. A dedicated cloud, as I understand it (and confirmed by details on competitor sites) is basically a webfarm front-end with possibly a database cluster on the backend (though often the term "cloud" is targeted toward the front-end solution).
Either these companies are new to the webfarm / cloud space, or they're just putting a marketing twist on existing services.
I guess I need to start getting comfrotable with using the term cloud now since it seems to be the new buzzword. Whether you call it a cloud, webfarm, server farm, or anything else - I'm all for HA/HS solutions and believe that anyone who relies heavily on their web site/application being online should go this route. It's the best way to avoid costly downtime that might otherwise occur with hardware failure or resource overload.
When it comes to system administration I have one very simple rule: all repetitive tasks should be scripted.Sure you may spend a day or two, or longer for those especially pesky tasks, hammering out a working script, but once that script is written you can use it indefinitely for years to come.And what better way is there to script in Windows than PowerShell?I dare you to say VBscript, I could use a good laugh today – I’ve had a nasty head cold for the past few days.
Speaking of being sick, why is it that you always get sick on, or just before, a weekend or holiday?
Back to the task at hand.To make a long story short, and those who know me can attest to my long-windedness, I needed to develop a script which would call our SQL server and grab a list of available servers, then remotely pull the server’s detailed hardware and operating system information through WMI, turn the WMI goobly-gook into pretty HTML, and lastly upload that information to the sales team’s SharePoint site.Piece of cake, right?
Did I mention the most I’ve programmed since I completed my Java programming class in 1998 were some simple batch files?I didn’t think so.This script is a testament to how easy it is to learn PowerShell, how strong the community is, and how flexible the language/shell is.PowerShell 2.0 is going to be even better, too.But I digress, let me show you the outcome of my system information script – slightly edited for security reasons.
I also made a stand-alone variant of this script for data center duties so I can get a quick peek at a system if a client requests an upgrade. This will be the variation on the system information script that I will ultimately be detailing in this series of blog posts.After that I’ll go into customizations that can easily be implemented by strategically adding a function here and there.Tune in next week and I’ll get into the juicy yumminess of the script.
