I stumbled across information about the Widget Channel this morning. It's a joint venture between Yahoo and Intel.

http://connectedtv.yahoo.com/partners/intel

I'm a big fan of all things mobile. I think a key benefit of the Internet is accessing resources (whatever they might be) from any location. PDAs, notebook PCs, tablet PCs, wireless cards, etc... I love the advancements in these areas and I think they're key to the future of the Internet. So, when something new comes out, I like to test it to see what progress we're making toward an "Internet anywhere" environment. Hence the reason for some of my posts that talk about mobile devices and don’t seem to be hosting related (they are – sort of).

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.

 

PowerShell Tip of the Week link:

http://www.microsoft.com/technet/scriptcenter/resources/pstips/feb08/pstip0208.mspx

Details on the System.Windows.Forms namespace:

http://msdn.microsoft.com/en-us/library/system.windows.forms.aspx

 

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:

http://blogs.msdn.com/powershell/archive/2008/05/22/wpf-powershell-part-1-hello-world-welcome-to-the-week-of-wpf.aspx

In part 3 I will dive into the main function body, followed by generating the HTML in part 4.  Part 3 coming soon™.

#James Kehr
Get-Member $OW | ?{$_.title -eq "System Administrator"`
-and $_.certification -contains 'MCSE 2000, MCDST, Network+, A+'}

New-Variable -name company -value 'ORCS Web, Inc.' -description ‘www.orcsweb.com | 1.888.313.9421’

I was surprised to find that this SQL statement does not return .36 as I had expected:

select 36/100 as ShowPercent

From some online searching I found a post which commented that a decimal result from a division operation would not display properly if both of the values were integers. I have no idea why, but that does seem to be true. The change I made to get the correct result was:

select 36/cast(100 as float) as ShowPercent

~Brad

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.

At ORCS Web we have been hosting highly-available and highly-scalable webfarm solutions for clients for over ten years. Here's a short case-study about a webfarm solution we manage for Lake Quincy Media. We also host webfarm / cloud solutions for http://www.asp.net/, http://www.zagat.com/, http://aspalliance.com/, and many other clients.

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.

Happy Hosting!

~Brad

 

I ran into an interesting dilemma yesterday.  While converting my two OpsMgr 2007 Agent install scripts from batch file to PowerShell I hit a snag with the most important part of the script, the actual installation of the OpsMgr Agent.

To manually install the OpsMgr Agent with customizations you have to use msiexec.exe with a ton of flags.  Doing a cut & paste of the install line from the batch file was a resounding failure.  So was using an invoke-expression and several other methods I tried.  Eventually I ran into this forum post which gave me the solution I needed.

http://www.vistax64.com/powershell/101954-executing-cmd-exe-powershell.html

I'm not going to bother with the entire script, but my installOMAgent function ended up looking like this:

The code is fairly easy to follow.  First, I pull the OS information using a WMI call, then determine if the OS in question is 32- or 64-bit.  The $arch variable is then created to determine the MSI path for the appropriate agent version.  I then break down the agent install line into variables.  $INSTALLDIR sets the install location, and $argue sets the rest of the custom installation arguments I chose for the installation.

From there I run a switch statement to finish the installation command-line based on what operating system architecture is present and then store that finished string in variable named $call.  The installation then runs, pausing the script during so it does not continue until the application is present.  Lastly I run one last check to see if the OS is Windows Server 2008. If it is I add the firewall rule needed for the health service to work in the prescribed bi-directional manner.

That's it!  Piece of cake.  As with all PowerShell functions, this little snippet of code can easily be modified for any number of .msi packages.  Just tweak the contents of a few variables, dump the code into a different installation script and viola!  New installer script in record time.

#James Kehr
Get-Member $OW | ?{$_.title -eq "System Administrator"`
-and $_.certification -contains 'MCSE 2000, MCDST, Network+, A+'}

New-Variable -name company -value 'ORCS Web, Inc.' -description ‘www.orcsweb.com | 1.888.313.9421’

One setting that is hidden within many panels of Urchin 6 is the memory setting, which sets the amount of memory Urchin is to use when processing.  This setting was set to 128MB in our default install but can be increased to 1024MB.  Once we changed this setting there was an increase on log processing times of around 70%.  Here is where to find this setting:

1.       Login to Urchin with an admin account

2.       Click on Settings

3.       Select the DB Settings Tab

4.       Under Memory Usage Target, Select a larger amount and click the update button.

Jeff Sandquist announced on his blog that his team has released Oxite, a new open-source content management "sample" (I'm not sure what makes it a sample, but that is the word used on the site) for people to use when adding blog and wiki functionality to their websites.

Check it out:
http://www.jeffsandquist.com/supporting-web-standards-with-microsoft/
http://visitmix.com/Lab/Oxite

Brad

If you are interested in data center advancements, and have a lot of time on your hands to read and digest a lot of content, you might want to check out this recent long blog post by someone in Microsoft's Global Foundation Services department.

http://loosebolts.wordpress.com/2008/12/02/our-vision-for-generation-4-modular-data-centers-one-way-of-getting-it-just-right/

 

So much for the demise of McColo causing SPAM levels to drop by 75%. The level of spam as tracked by our devices for the most recent week ran right around 96%. That's right - only 4% of the email was legitimate email.