Tag: Powershell

A PowerShell Script to Assist WCF Service Hosting / Testing

When developing for WCF, I find situations in which I need to manually host the WCF services.  (“Manually” == “not from within Visual Studio”).  Sometimes I have to go back and forth between different services, etc.  The command I really wanted was to be able to “just host from here.”  So, I created a simple PowerShell script that does just that.

WCF-HostMe starts in the current directory and looks for a service to host.  It simply looks for a config file (matching *.[exe|dll].config) and assumes that the config file’s name-matching exe or dll is the service.  After formatting and building the parameter values, it launches the service using WcfSvcHost.exe.

Again, this is a simplistic approach and really only works well for development and testing purposes.  Obviously this is not a good approach for production environments.

 

###### WCF-HostMe.ps1
#    Hosts a WCF service using WCF Service Host (WcfSvcHost.exe) for testing purposes.
#    How it works:
#        Beginning in current dir, recursively searches for *.exe.config or *.dll.config
#        Assuming the .config file is asso'd with the WCF service, launches WCFSvcHost
#            using the service's and config's paths
#
#    History:
#        3/16/2012, J Burnett    Created
#####

# Find .config file
# TODO: handle multiple search results
# TODO: detect assembly is not hostable? (not WCF, WF)
$configPath = (gci . -include *.exe.config, *.dll.config -recurse).VersionInfo.FileName

# Build WCFSvcHost param inputs - the full paths of service & config
$serviceArg = (" /service:""" + $configPath -replace '.config','') + """ "
$configArg = " /config:""$configPath"" "

# Launch WCFSvcHost to host the service
echo ''
echo "Attempting to host $serviceArg as WCF Service..."
start-process WcfSvcHost.exe -ArgumentList ($serviceArg + " /config:""$configPath"" ")
echo ''


### Copyright & Disclaimer
#####
# This software is provided "as is"; there are no warranties of any kind.  This software 
# may not work correctly and/or reliably in some environments. In no event shall
# AltaModa Technologies, LLC, its personnel, associates or contibutors be liable for 
# ANY damages resulting from the use of this software.
#####

Get-Sysinternals–Not for Windows Servers

I recently posted about Keeping SysInternals Up-To-Date. Since then I’ve had trouble getting it to work on any of our Windows Server machines.  I couldn’t find much info on this online, so maybe it’ll be helpful to raise the problem here.

There is a problem with Get-Sysinternals.ps1 that prevents it from working on Windows Server platforms.  The problem is due to its dependence on WebClient – the service that provides the ability to treat a URN on the web as a local drive.  The specific line in Get-Sysinternals is:

New-PSDrive -Name SYS -PSProvider filesystem -Root \\live.sysinternals.com\tools

When WebClient is active, this line successfully creates a local drive called SYS that points to \\live.sysinternals.com\tools.  When WebClient is not active, this line causes an error:

 

New-PSDrive : Drive “\\live.sysinternals.com\tools” does not exist or it’s not a folder.

At …\Get-Sysinternals.ps1:26  char:15

+ New-PSDrive <<<< –Name SYS -PSProvider filesystem -Root \\live.sysinternals.com\tools

     + CategoryInfo : ReadError: (SYS:PSDriveInfo) [New-PSDrive], IOException

     + FullyQualifiedErrorId : DriveRootError, Microsoft.PowerShell.Commands.NewPSDriveCommand

Is the solution to simply turn on the WebClient service?  Unfortunately not.  The official method for installing WebClient is to turn on the Desktop Experience feature. Microsoft does not offer another way (see Installing WebClient Service without Desktop Experience?)  Desktop Experience also includes (reference Desktop Experience Overview, TechNet): 

  • Windows Media Player
  • Desktop themes
  • Video for Windows (AVI support)
  • Windows SideShow
  • Windows Defender
  • Disk Cleanup
  • Sync Center
  • Sound Recorder
  • Character Map
  • Snipping Tool

Hmmm. We don’t want any of these running on our servers.  Not only do they violate the Least Required Principle, many of them are CPU hogs (Themes, SideShow, Aero), others may execute at unknown times (Disk Cleanup, Sync Center), etc.  Which of these involve installing drivers (Video for Windows?)

No, Desktop Experience is far from appropriate for gaining the functionality of WebClient (which we would only run temporarily anyway).

 

So, back to the drawing-board.  What are others doing to update SysInternals on Windows Servers?  Is anyone interested to collaborate on adapting the Get-SysInternals script to work for servers?

Keeping SysInternals Up-To-Date

Ed Wilson, Microsoft Scripting Guy, has a good article on TechNet about automatically keeping your local SysInternals files up-to-date.  If you use the SysInternals tools, you know that they are updated fairly frequently – often due to suggestions from outside Microsoft.  If you aren’t using SysInternals, well, you should start.

Scripting Guy’s article is a bit long-winded (in a Spencer F. Katt way), so here’s the quick and dirty for getting started.

  1. Copy the Powershell script, Get-Sysinternals.ps1, from the TechNet Gallery
  2. Paste the script into your favorite editor and save it to the location where you keep scripts (e.g., %UserProfile%/Scripts)
  3. Open Powershell or Powershell ISE as admin (otherwise the script provides a warning: This script requires running as an elevated administrator
  4. Before running the script, make sure you know exactly where SysInternals tools are stored (e.g., %ProgramFiles(x86)%/SysInternals).  You’ll provide this path when you run get-sysinternals.ps1.  If you don’t provide a path, the script will put the SysInternals tools in %SystemRoot%/SysInternals.  Call me paranoid, but I don’t like making changes within %SystemRoot% if it can be avoided.
  5. Run the script.  For example, I run the script like this:

Get-SysInternals “${env:ProgramFiles(x86)}/SysInternals”

Don’t forget the curly braces, or you’ll end up with a path like C:\Program Files(x86)\SysInternals (note the missing space b/t Files and (x86))

 

Here’s a screenshot of the output on my machine:

image

 

Worth noting:

  • Colorized output is a very nice touch!
    • New apps / utilities are reported in green
    • Updated apps / utilities are reported in yellow
    • Unchanged apps / utilities are reported in white
  • The script appears to re-write your machine’s path environment in a different order!  (See the Old Path and New Path sections of the screenshot above) I wasn’t expecting that, and I’m not sure I like it.  That’s a pretty aggressive move.

 

I’m pretty satisfied with manually executing this script occasionally.  Automating it, I have to admit, is pretty cool, however.  So, if you want to automate the script, check out Scripting Guy’s article.

Now, if we just had a way of keeping Get-Sysinternals.ps1 up-to-date.  Smile