Get-wmiobject "User credentials cannot be used for local connections"

In Advanced event 2 of the 2013 scripting games, I was going through scripts and thinking it was very strange that people were creating separate blocks of code to do get-wmiobject calls that involved the local machine. This is somewhat disturbing when you are writing code that hits a long list of machines that may include your own local machine. Having to add all the constant checks to see if you are on the local machine seems like a bit of a pain. I can't think of any great work around for this that isn't going to cause additional problems, but you could just let the call fail and pick it up in a catch block. One other option, which creates seperate powershell processes would be:

start-job -credential $cred -scriptblock {get-wmiobject -class yourclass -computer $args[0]} -argumentlist $computer

Then go back and receive-job on the output to process it.

Managing large sets of scripts

Over the last year I have been rolling out a lot of Powershell functions that I like to have readily available in my profile. Originally this was one large block over roughly 2000 lines of code, which gets a bit unmanageable. Eventually I created a base profile, a secondary profile with reference functions, and multiple executable and header files to split up functions based on usage. This has become 42 files and 5300 lines of self updating and centrally managed code with stable and beta sets. As this set of files continues to grow rapidly, I am evaluating the design principles again to see if there are any better solutions out there. This is what I have at the moment:

1) Base profile. Changes between beta copy and production copy on a function call that overwrites the file at $profile with the appropriate version. This base profile checks all files at a specific network share, either prod share or beta share, compares a set of files on the local system with the ones on the share for any changes/new files that need updating, updates and applies the secondary profile with the "." operator.

2) Secondary profile. Contains a few complete functions for parsing system names, command line options, and a few other functions that don't fit well in other files. Besides this there are pointer functions that call external scripts at ($localpath + "extFile.ps1"). These calls can directly call a stand alone script, or call a script that contains multiple executable functions. In this case, the name of the function + arguments is passed and interpreted by something like this:

$server = $args[0]
$function = $args[1]
&$function $server

3) External scripts. Stand alone that manage arguments passed. Options passed are general hash table's with switches or valued arguments passed. External scripts may load header type files with the "." operator. Since the files are separate from the profile, the scripts may be updated by another process without reloading the profile.

4) Header files. Contain a range of functions for a specific area (hardware, directory, security, etc) that would not be very useful when used directly. Functions here may be required for several different executable functions. They also allow for rapid development of future executable functions. The problem here is designing functions that are useful for what you are doing when you write them, and still usable for other code without having to be rewritten, or written with excessive capabilities the first time.