As a Premier Field Engineer, I am constantly doing presentations and delivering workshops to large groups of people, usually about PowerShell.  One of my favorite tools to use is ZoomIt which is part of the SysInternals suite.  I may not use ZoomIt for its “break” feature since I have my display-countdown script, but it’s a really great tool.  It can however be difficult to remember all of the shortcut keys if you haven’t used it before (and even to someone who uses it all of the time).  A while back I created a little printable card of all of the shortcut keys that are built in so I could tape it to the presentation screen and never fumble through it.  I decided to redo the card using a metro inspired design and am now sharing it with you!

The image is set up for 300 dpi and will print the same size as a business card.  Be sure to print it with the best options set on your printer and maybe you can even laminate it, if you want, and keep it in your gear bag.

Download the high-res version: Printable ZoomIt Shortcut Card.

While Get-Member can give us an awful lot of information about the methods, properties, and other members of a specific object, you have to jump through a few hoops to make all of the information display in an easy to read format. If you want to see static members you have to change around your call to Get-Member entirely.  The only way to get real reference / help information is to open up the MSDN library and look the information up.

This got me thinking, instead of dealing with all of the MSDN documentation manually, why not just create a script that will open up MSDN for me to the page about the specified type? This isn't a difficult process, but there are many different URLs that the script would have to be aware of to make sure it always loads the correct page that it became a bit messy. Therefore I opted for a much simpler option: just make the script load the MSDN search page with the specified type queried for me.

Jump past the break for more info and to download the script

The script allows input in the form of Type, MemberInformation, or just a String. The nice thing with MemberInformation is that you can do something like:

Get-ChildItem | Get-Member | .\Find-TypeReference.ps1

This will send the member information Get-Member returns and will look through it to figure out the data type and then pass it off to the web browser.

Since not every type will be defined in the .Net Framework because some could be third party types that don't exist on MSDN it also allows you to open up Bing instead to do the search. Combine this with the fact that it allows you to specify a string query, and now you have a function that will not only search for type information based on objects piped into it, but also open up a search for just about any query you can think of.

Additionally, this script uses ShouldProcess to make sure you don't pass in hundreds of different types and end up bringing your computer to a crawl by launching too many instances of a web browser for the search page.  Stay tuned for a future post which will talk about ShouldProcess and how to use it in your own scripts.

Download Find-TypeReference.ps1

I was excited about the Windows 8 developer preview that was released earlier tonight, so I fired up Virtual PC to start playing around with it.  I ended up with an error when it was loading so I thought maybe I had a bad copy of the ISO so I thought "I know, I'll do a checksum test."  Unfortunately, I don't have a tool to take a checksum on my current machine so naturally I wrote a simple function in PowerShell to do the checksum test for me.

It has only a few simple parameters that you can enter, file and algorithm.  "File" is for the actual file you want to checksum.  "Algorithm" is either "sha1" or "md5" and will let you get both an MD5 and a SHA1 checksum of the specified file.

Update: If you came here looking for the SHA1/MD5 hashes for the Windows 8 CTP iso’s, here you go.

Windows Developer Preview with developer tools English, 64-bit (x64)
SHA1: 6FE9352FB59F6D0789AF35D1001BD4E4E81E42AF
MD5: 116EB08542BB48FE4314BB6DEA39335E

Windows Developer Preview English, 64-bit (x64)
SHA1: 79DBF235FD49F5C1C8F8C04E24BDE6E1D04DA1E9
MD5: DFCB53C7B32351784C37E5DE0A7B1167

Windows Developer Preview English, 32-bit (x86)
SHA1: 4E0698BBABE01ED27582C9FC16AD21C4422913CC
MD5: 9B7798438FA694ECFA465C93A4C23C97

You can download the full script after the jump.

function Get-Checksum
{
    Param (
        [string]$File=$(throw("You must specify a filename to get the checksum of.")),
        [ValidateSet("sha1","md5")]
        [string]$Algorithm="sha1"
    )

    $fs = new-object System.IO.FileStream $File, "Open"
    $algo = [type]"System.Security.Cryptography.$Algorithm"
	$crypto = $algo::Create()
    $hash = [BitConverter]::ToString($crypto.ComputeHash($fs)).Replace("-", "")
    $fs.Close()
    $hash
}

As a Premier Field Engineer for Microsoft, I'm often presenting workshops to classrooms of people on various technologies.  During these workshops we take breaks and work on labs and it's nice to have some kind of countdown timer to show the attendees how much time is left in a break or until we begin the next module for example.

Sysinternals has a very useful tool called ZoomIt which allows presenters to zoom in, draw, and even display a countdown timer on the screen.  While this tool is well designed and is even used by many PFE’s around the world, including myself, and while it includes useful features such as playing a sound when the timer has completed and even displaying a background image, it left me wanting more.  I just wanted something basic that I could use when presenting PowerShell material that would allow me to simply specify a time and a message… so I made my own.

Head after the jump to download the script.

I wrote a script that would allow me to display a popup countdown timer from within the PowerShell console.  The script I wrote is provides two different countdown timers: one is very basic and just displays a simple two line countdown, the other is a bit more advanced and displays an “F7 style” popup window like in the screenshot above.  It looks pretty nice even though you're still limited to the font size of your shell (I always have mine set high (12×16) for projection screens anyway).  You can use the built-in Windows magnifier to enlarge it even more if you really want.

Here are a few usage examples, but you can see everything by looking at the comment-based help by running get-help .\display-countdown.ps1 -full

Usage examples:

————————– EXAMPLE 1 ————————–

C:\PS>.\display-countdown.ps1 -Minutes 15 -Message "Time until break is over"

This will display a simple text-based countdown that will expire 15 minutes from the time it was called, displaying the specified message as a header.

 

————————– EXAMPLE 2 ————————–

C:\PS>.\display-countdown.ps1 -Until (get-date).AddHours(1) -Message "Lunch break" -Popup

This will display a countdown timer that will expire in one hour from the time it was called, displayed "Lunch break" as the caption.  This example displays in the more user friendly popup mode.

 

————————– EXAMPLE 3 ————————–

C:\PS>.\display-countdown.ps1 -Countdown ([TimeSpan]::FromMinutes(10)) -Message "Bio Break" -NoClear

This will display a simple text-based countdown that will expire 10 minutes from the time it was called, displaying "Bio Break" as the header.  This call does not clear the screen of its contents before running. 

Download display-countdown.ps1

An interesting situation came up recently that involved having to execute a PowerShell script through the cmd.exe command prompt. It sounds pretty simple, after all you can simply run powershell.exe –file “<path_to_script>” and call it a day. That wasn’t the case here though because the –File parameter is only available in PowerShell V2 and this situation was dealing with V1. The only option then is to use the -command argument of powershell.exe and to execute the necessary code. This works great, but if you need to include a string with quotes, you may have some trouble.

Scroll to the end for the summary if you just want to see how to properly get quotes into your powershell.exe -command argument.

Within PowerShell, it is incredibly simple to execute a script (assuming your script is signed or you have the execution policy set appropriately). There are a few gotchas that people get caught up on when they are starting out with PowerShell so I’ll quickly cover them first.

We want to execute the script, so we just provide the full path to the script and hit enter, right?

That didn’t work because of the spaces in the path. Ok, then we just proceed like we would in a command prompt and put the path in quotes, right?

Unfortunately that doesn’t work either because now you are just telling PowerShell “Hey, here is a string” and it simply spits it back out to you. The correct procedure is to use the Call operator with the entire path in quotes and it should work out fine.

Then, if we want to use the environment variable for the program files directory, we can just do the following:

Now that we know the proper command syntax, we need to switch over to a command prompt, since this script has to be executed from there. We know that powershell.exe can accept a –Command parameter which should allow us to execute the same command we just figured out within the PowerShell prompt.

That doesn’t work, but what exactly is going on here? Based on the output of the error, we can see that the environment variable is being expanded appropriately, but it looks like everything past “script” is being interpreted as an additional parameter. With this in mind, it seems like it’s a simple matter of having to escape the quotation marks around the path of the script to make sure it’s interpreted as a single value. Because we are in a dos prompt though, the first thought might be to use a caret (^) to escape the quotes, which is something we do all the time in batch files.

That doesn’t work either, but the error is slightly different this time. Instead of the intended result of having a quotation mark, the quotes are actually dropped and the caret is inserted. So clearly the caret didn’t help, so next we try the PowerShell escape character, the grave accent (`). This may make more sense because the logic is that whatever is inside the outer quotes, gets passed into the PowerShell executable, then the rest of it gets interpreted. Therefore we need PowerShell to be aware of what we are doing.

Interestingly, the environment variable isn’t being expanded now; additionally the grave accent isn’t being passed at all. It’s as if PowerShell is completely disregarding the text we are inputting.

So what is actually going on here? As it turns out, we aren’t dealing with an issue with choosing the right escape character for DOS, or the right escape character for PowerShell. The problem is that we need to use an escape character that the PowerShell argument parser can understand. The powershell.exe binary isn’t a batch file or powershell script, it is an actual compiled program and as such has to actually parse the arguments that are given to it. With that in mind, we need to use the appropriate escape character, the backslash (\).

So what is the conclusion here? When trying to execute a command in PowerShell via the -Command argument of powershell.exe, be sure to escape your quotes with the C style back slash.

This behavior is by design, there is no doubt there. Ultimately, it all comes down to how the application (powershell.exe in our case) parses the command line arguments. PowerShell handles it this way whereas another app could in theory have it’s own, completely made-up, set of escape characters for arguments that are enclosed in quotes. While it may be confusing when trying to execute commands via the PowerShell binary, this actually is logical behavior when you think about it, and once you are aware of how it works, you will likely never forget.

One thing to note about the examples I am using below: they are only intended to show how these would look in a block of code, rather than demonstrate real-world usage. Refer to the MSDN article links for more detail on actual usage of each delimiter.

So, without further ado, here is the full list of ASP.NET code delimiters.

<%
'Basic inline code block
For x = 1 to 100
    Response.Write string.Format("x = {0}<br />", x)
Next
%>

Current Date and Time: <%= DateTime.Now().ToString() %>

<%-- You can use a server side comment to keep information from getting to the browser of a user --%>

<%@ Page Title="Home" Language="VB" MasterPageFile="~/Site.master" AutoEventWireup="false" CodeFile="Default.aspx.vb" Inherits="_Default" EnableSessionState="False" %>

<asp:DropDownList ID="ddlInsertUser"
                        SelectedValue='<%# Bind("UserID") %>'
                        DataSourceID="UsersDataSource"
                        DataTextField="UserName"
                        DataValueField="UserID"
                        RunAt="Server" />

<asp:Label id="label1" runat="server" text="<%$ Resources: LocalizeData, WelcomeLabel %>" />

The modified certutil command looks a bit like this:

certutil -view -restrict "NotAfter>=8/9/2010,NotAfter<=9/9/2010" -out "Request ID, Request Submission Date, Request Common Name, Requester Name, Request Email Address, Request Distinguished Name, CertificateTemplate, NotAfter" -config "<CA_SERVER_NAME>\<CA_NAME>"

This will return to you all of the certificates that are scheduled to expire between today (August 9th, 2010) and 30 days from now (September 9th, 2010)

You can download the new script here: Download monitor_ca_expiry.ps1

Update: Thanks to Aaron (from New Mexico? the original reader) who noticed I forgot one really useful bit of information from the status report that displays when you run the command: the date of expiration for the certificate.  I have updated the script and the sample above to reflect the change.

One thing that is a bit frustrating is that even when you have the logging options fully enabled for the CA, events aren’t logged for new certificate requests so you have to manually check the server on a regular basis for outstanding requests. Usually this is a low priority kind of service in your enterprise and can get neglected, which has happened in my case a few times.

This neglect prompted me to write the following Powershell script which very simply uses certutil to check if there are any pending requests, and then fire off an email to a list of users if there are. This script could also be easily modified to check for revoked certificates or to generate a weekly report on existing certificates to monitor expiration dates, among a bunch of other things, however I really only needed this for requests so that’s all it does for right now. If anyone has any interest in something else, let me know and I’ll see about updating the script to include additional features.

To use this script, all you need to do is ensure you have a copy of certutil on the machine running this, update the configurable pieces of the script, then create a scheduled task to run it every hour or so, or whatever time-frame is appropriate for you and your organization.

More information and a download link is after the break…

The script uses a very simple function of certutil to check for pending requests. You can execute the following code from a command prompt or powershell prompt to see a list of existing pending requests.

certutil -view -out "Request ID, Request Submission Date, Request Common Name, Requester Name, Request Email Address, Request Distinguished Name, CertificateTemplate, Request Disposition" -Restrict "Request Disposition=9" -config "<CA_SERVER_NAME>\<CA_NAME>"

Basically what this is doing is it is telling certutil to check for any certificates where the request dispoition is 9, in other words, any pending certificate requests. It then outputs a few usefull properties related to the certificates. All you need to change is the part with “\” to include the valid server and name.

Note: You can omit the entire “-config “<CA_SERVER_NAME>\<CA_NAME>”" piece if you are running this locally from the CA server and only want to retrieve the local information.

For the full powershell script, click the download link here: Download monitor_ca_requests.ps1

Update 2010-03-03: Keep in mind that this was fixed in vSphere 4 Update 1. Although if you can’t move to Update 1 for some reason, this will still work.

Update 2009-09-08: I just updated the script because I received a report from wohali (Joan) over at VMware communities that they had a problem when the vSphere client was installed on a different drive and I have now fixed that problem.  I also added in support for making the host update utility work as well.  Lastly, I added a few output messages so you can see what’s going on and know what is getting done.

The past few months I have been enjoying Windows 7 quite a bit (both the RC and now the RTM), but at the office we use VMware for many of our clients and the vSphere Client unfortunately has an issue with Windows 7 due to an incompatibility with a .Net 2.0 library dll that comes installed on Windows 7.  When you install the vSphere client, you will be able to get through the install without an issue usually (If you have J# already installed you may encounter issues installing the vSphere client), but once you try to connect to your vSphere server you get an error stating “Error parsing <server> clients.xml file  Login will continue contact your system administrator” followed immediately by another error “The type initializer for “VirtualInfrastrcture.Utils.HttpWebRequestProxy” threw an exception” which then brings you back to the login screen and you are unable to connect in.

There’s big thread over at VMware Communities that discusses this problem and ways to fix it.  Unfortunately, it’s a manual process and deploying this out to all of our Windows 7 employee workstations is a bit of a hassle, so I have created a Powershell script that will do the necessary work for you, and create a shortcut on your desktop as well.

By default, powershell security options may prevent you from executing the script, so you may have to change a setting temporarily to get it to work.  If you type “Get-ExecutionPolicy” from a powershell window you will most likely see “Restricted” but there are a few others as well which will all prevent you from executing the script.  You can read more about this over at dotnetvj.com where he goes into a little more detail about these execution policies and what they mean.  All you need to do though is type “Set-ExecutionPolicy Unrestricted”  Just remember that you should probably set the execution policy back to its previous value after you run the script for security purposes.  Lastly, you will also need to run powershell as an administrator if you have UAC turned on because this script has to add files to the installation folder of your vSphere client.

Launch Powershell as Administrator

Once you have powershell running as an administrator and change the execution policy, it is a simple process to run this script, simply CD to the folder that you have extracted the script, and run it by typing “.Windows7vSphere.ps1” and it will do the work of copying over the System.dll and creating the necessary files to launch vSphere client in development mode so it can use the System.dll.

Change execution policy and execute Windows7vSphere.ps1

You should now have an icon on your desktop called “VMware vSphere Client (Windows 7)” which you then simply run as administrator to launch the vSphere client.  The reason you have to launch it as administrator is because it creates an environment variable that lets the vSphere client know that you are giving it a different System.dll to work with.  This is something also discussed in detail in the thread over at VMware Communities.

For anyone interested in powershell, this script also shows a few cool things such as reading from the registry, writing to an xml document, as well as creating a windows shortcut using pretty simple commands.

Hopefully this will help a few people streamline the process of getting the vSphere client installed on your Windows 7 machines.  If you notice any problems with the script, feel free to comment and let me know and I’ll try to fix it as soon as possible.

Download the script and the dll needed here: Download Windows7vSphere.zip

The issues I experienced were while creating a page to display general status of one of my companies Sharepoint servers. The main issue which is the meat of this article was when I switched the authentication over to use NTLM instead of Digest, which broke my script. Everything I had in place should have worked, but the previously mentioned security update slipped under the radar and it took a while to figure out what was going on. You can do a basic web request on a server with Basic authentication by doing the following:

Dim _response As String
Dim _auth As String = "Basic"
Dim _uri As Uri = New Uri("http://my.domain.local/my-page.aspx")
Dim _req As HttpWebRequest = WebRequest.Create(_uri)
Dim _cc As CredentialCache = New CredentialCache()
Dim _res As HttpWebResponse
Dim _sr As StreamReader

_cc.Add(_uri, _auth, New NetworkCredential("username", "password", "domain"))
_req.PreAuthenticate = True
_req.Credentials = _cc.GetCredential(_uri, _auth)
_res = _req.GetResponse
_sr = New StreamReader(_res.GetResponseStream)
_response = _sr.ReadToEnd
_sr.Close()

That code works perfectly well with Basic and even Digest(if you change the _auth value) authentication, however it will most likely not work for you if you are using NTLM authentication and your server has had the MS08-068 patch applied to it. Prior to discovering the conflict with this patch I went through a lot of effort to investigate the issue. One of the most useful debugging utilities in IIS7 is the failed request tracing logs. These logs give you really great insight as to what is going on inside your web request traffic. You can also use a tool like Fiddler to try and see what’s happening, but unfortunately because our Sharepoint server was live, it would have caused SSL certificate issues if I put it in the mix in my situation.

After looking at the failed request traces logs, I noticed an interesting difference between one of the failed requests from my health check script and a purposely failed request through a web browser that I pointed to a file I had no access to read.

401.3 Error message – Unauthorized due to ACL on resource

401.2 Error message – Logon failed due to server configuration

Note: Check out http://support.microsoft.com/kb/943891 for all the status codes in IIS7

The difference here is that on the WebRequest, it wasn’t even getting an NTLM token from the .Net app. This lead me astray however and made me think that there was a problem with the pre-authentication of the credentials as well as whether I was missing something in the web.config, or even if it was some unique problem with Sharepoint. After a lot of investigation I discovered the Microsoft KB article titled: “You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or IIS 6” After giving a thorough read of that document I realized the problem, Microsoft forgot to update the title of the KB article. The sub status code I was getting on the 401 errors is different than Microsoft mentions in the article, and while they don’t mention IIS 7 in the article’s title, it does show up in the applies to section.

Since Microsoft recommends you leave the loopback check in place because it is part of the security update, I followed their recommended method of adding in a specified host name to the BackConnectionHostNames key in the registry.

As always, make registry modifications at your own risk, Microsoft always recommends you make a backup before making any modifications, check out the following KB article for backup instructions: http://support.microsoft.com/kb/322756

Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. TinyInt.Com cannot guarantee that these problems can be solved. Modify the registry at your own risk.

To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:

1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate and then click the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

1. Right-click MSV1_0, point to New, and then click Multi-String Value.
2. Type BackConnectionHostNames, and then press ENTER.
3. Right-click BackConnectionHostNames, and then click Modify.
4. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
5. Quit Registry Editor, and then restart the IISAdmin service.

Now that you have taken care of editing the registry to include the hostname you are using in your code, you should be able to make your WebRequest over NTLM without a problem, just make sure you have impersonate=”true” in your web.config file.

Attached below is the code for the health check script that I have been talking about throughout this article. As I mentioned earlier, it does some very basic checks on the server just to see if things are running smoothly. To use it you would simply need to change the variables being passed into the various functions to check your database connectivity. We use WhatsUp Gold to track the value of ALL_STATUS_OK to make sure things are working properly, and once one of the values fails it sends us an alert. Another thing to keep in mind is if you are using the WebRequest piece in this code, make sure you grant the user you are authenticating as access to the Sharepoint page you are checking. Lastly, if you use the code, make sure you read the comment in the web.config file about encrypting the settings so your password is not exposed, even if you are using a low privileged user account.

Download Source: Download sharepoint-contentscan.zip