Specifically, get/set-content works with providers that facilitate content reading and writing. Out-File works only with the FileSystem provider and is for all intents and purposes an alias to the > redirection operator.

An interesting thing to note about get-content and set-content is that you use them indirectly every day. Both the variable and function providers support get- and set-content, and when you use the dollar ($) syntax to read or write to a variable, you are implictly calling get-content and set-content against a path in the variable provider. E.g.

...is the same as:

e.g. set the content of item foo in the psdrive called "Variable" to 5. This is why you can also write to a file like:

...and read it back with:

Ultimately, when using the $ syntax, the "variable" drive is the default drive to read and write content from. Elegant, eh?

Resharper (or R#) is an absolute gem of a tool. After using it for a year, I really don’t know how I got along without before. If you write code in .NET (C# or VB.NET), you owe it to yourself to try it out. Version 4.0 was the first to support C# 3.0:

ReSharper 4 Full Edition and C# Edition extend language support to C# 3.0, including LINQ, implicitly typed locals and arrays, extension methods, automatic properties, lambda expressions, object & collection initializers, anonymous types, expression trees, and partial methods. ReSharper not only analyzes the new constructs, but provides C# 3.0-related enhancements in a number of areas — specifically, warnings, suggestions, code completion options, refactorings, and templates.

The guys at Jetbrains just released versus 4.1. They offer a free thirty-day trial over at http://www.jetbrains.com/resharper/ – do it!

Are you sick and tired of switching the VMWare virtual network adapters from the “public” network profile to a “private” network profile each time you reboot or do something else that causes Vista/Win2008 to forget what you told it to do ten minutes ago? This is probably a familiar sigh (I’m using Workstation):

As you can see, the lower two connections are seen to be in a “Public network.” This has the net effect of making Windows believe the whole machine is exposed to a public network, and it will trigger the public profile for Windows Firewall. This is normally a good thing, but in this case it’s just an annoyance. These two network connections are not actually external gateways that can let in the bad guys. They are just dummy adapters for VMWare’s host bridging which allow the virtual machine to access the host machine’s network. Because they don’t identify themselves properly, they are flagged as an “unidentified network,” and your changes are never persisted.

So what do you do? The magic information is buried in MSDN:

Vista automatically identifies and monitors the networks to which a computer connects. If the NDIS_DEVICE_TYPE_ENDPOINT flag is set, the device is an endpoint device and is not a connection to a true external network. Consequently, Windows ignores the endpoint device when Windows identifies networks. The Network Awareness APIs indicate that the device does not connect the computer to a network. For end users in this situation, the Network and Sharing Center and the network icon in the notification area do not show the NDIS endpoint device as connected. However, the connection is shown in the Network Connections Folder. Also, if NDIS_DEVICE_TYPE_ENDPOINT is set, the Windows Firewall ignores the connection when Windows Firewall enforces public, private, or domain policies.

So I hacked together a PowerShell script that will scan your adapters for VMWare’s virtual NICs and make the necessary registry changes. It will also disable/enable cycle the adapters so that the changes take effect. After this is done, you will see them in your Network Connections page – albeit lacking a network category -- and the connections will no longer appear in the Network and Sharing Center nor will they affect your Windows Firewall policy no matter how many times you reboot!

Here’s the script source below. It requires that you run it in an elevated shell in order to write the registry changes and cycle the adapters’ enabled state.

Have fun.

The new eventing infrastructure in PowerShell 2.0 is pretty delicious. You couldn’t do the following in 1.0 without a 3rd party snap-in (like my PSEventing snapin), but now it’s all there at the touch of your fingers. Well, it demands a bit of a sniff around WMI too, but hey, it works well.  With this module, anytime you add or remove a removable device like an external harddrive or USB key, or map a new network drive in explorer, PowerShell will now automatically add or remove a corresponding PSDrive for you.

• Link to PoshCode Copy

This only works PowerShell v2.0 CTP2, and you’ll need to save it as AutoMount.psm1 in a directory under your documents folder like so (vista example):

%userprofile%\documents\windowspowershell\packages\automount\automount.psm1

You can then load it with the command:

ps> add-module automount

I have this in my profile.  You can temporarily disable automount with the function Disable-AutoMount and reenable it at anytime with Enable-AutoMount. The module also exposes four new events for you to consume yourself. You could, for example, hook your own script to run anytime a device is added and/or removed. This is what I do myself in the module. I hook a WMI event once then forward 1 of 4 possible new events depending on the type of WMI event that was raised.

NOTE: this particular flavour of WMI query only works in Vista and Windows 2003 it appears. I’m looking into getting it working with 2000/XP also.

Have fun!

It’s getting harder to post useful scripting tips for PowerShell these days as there are so many talented hardcore scripting bloggers around. My day to day is job is not system/network/server administrator; I’m a .NET developer, having started the C# habit about eight or nine years ago with the early CLR 1.0 beta. So, from here on in, I’ve decided that a better direction for me to take from now on is that of a PowerShell developer,  as opposed to a scripter. There are very few (if any?) dedicated PowerShell developer blogs around, and so I figured I should try to fill that gap as best I can. I have a not insignificant amount of experience writing providers, cmdlets and other widgety bits, so it’s a good time to share my experiences. Of course, my way is not “the” way, so please reply with your own experiences/advice/mocking/whatever.

That said, I am not eschewing scripting altogether – I have some stuff in the pipeline (har-har) concerning areas I’m interested in, like eventing and jobs/remoting.

Just a handy tip - you don't have to cast enum types in powershell usually. It will do that for you if that's the only constructor (or method) overload that makes sense:

$accessrule = New-Object system.security.AccessControl.FileSystemAccessRule $userName, `
     "Modify",  "ContainerInherit,ObjectInherit", "None", "Allow"

So when I say "only overload that makes sense," what do I mean by that? Take this method for example which has two overloads (meaning it has two different sets of parameters you could use):

void MyMethod(string a, string b, string c)

void MyMethod(string a, enum b, string c)

If you try to call that method with $o.MyMethod("foo", "foo", "foo"), it will pick the first version that takes three strings. In that case, you would have to cast/convert the enum to its native type so that powershell will pick the right method.

With PowerShell’s new –STA startup switch, interacting with the Windows Forms object model was never so easy:

PS> $text = & {powershell –sta {add-type –a system.windows.forms; [windows.forms.clipboard]::GetText()}}

Easy, eh?

As we all [should] know, running scripts downloaded from the Internet is a risky business. But sometimes you know exactly where they came from, and you trust the source. The problem arrives when you’re on a server without any of your familiar utilities and you’ve just downloaded a zip of several ps1 scripts. Unzipping the zip via the windows built-in zip handler in explorer will preserve the Zone.Identifier information for the extracted files. This means that even if you have your Execution Policy set to RemoteSigned (which most people seem to have – it’s a sensible balance), the now “local” scripts are treated as remote and they will not run. Ideally you should “unblock” the zip file before extracting the files; all extracted files are then also “unblocked.” Unblocking a file is as simple as right-clicking it in Explorer and choosing “Properties.” (see figure 1).

Now, sometimes you don’t have this luxury. Either someone else downloaded/extracted the files or you are logged in remotely via PowerShell Remoting/WINRM for example. Thankfully, the annoyingly talented Mark Russinovich has written a great little tool for stripping NTFS ADS (alternate data streams – where the zone indentifier information is attached to a regular file) called streams.exe. He’s also made the tool easily available via a UNC path: \\live.sysinternals.com\tools\streams.exe Usage is simple: just start in the root directory of the extracted scripts and run: streams –s –d *.ps1 ; the –s means traverse subdirectories and –d instructs it to delete any alternate data streams from the files.