Yeah, yeah, I know.  Nobody cares about sticking a web application interface on top of System Center Configuration Manager.  Whatever.  I find it helpful for a lot of reasons (see below).  But in this episode of dumb projects, I’m going to focus on how to expose client tools in a web page.  Basically, that’s where you can drill-down to a particular device (computer) and invoke some remote management tools on it.  Some examples include browsing the C:\ drive, opening Computer Management and Remote Desktop.  But one more feature I wanted was the ability to launch a CMD console with WinRS and be able to run WinRM shell commands directly against the computer.

CAVEAT / WARNING / NOTICE / DISCLAIMER:

All machines involved in this situation are part of one common Active Directory Forest/Domain.  They all trust each other.  They go to lunch together.  They are on first name basis and swap birthday presents every year.  Don’t ask me about building this to bridge untrusted or non-contiguous Forests and Domains.

Back to the show… Below is an example of the tools form for one client device.

cmwt_tools

Prop your chin up on your hand and stare at that image for about 30 seconds.  Okay, you should have a firm grasp of what this is all about now.  The “Command” button is where I’m pointing my red laser light pen right now (you have to imagine it for now).

This is basically a way to open a Command console (e.g. “cmd.exe”) while streaming in the “winrs” command to invoke a remote shell session.  Obviously this incurs some additional considerations:

  • Windows Server 2012 R2 has WinRM enabled by default.
  • Previous versions of Windows, and most desktop versions, do not enable WinRM by default.
  • WinRM can be enabled easily using either:
    • winrm quickconfig (executed from a CMD console under Administrative context) – or –
    • Group Policy
  • As far as dealing with any cross-Forest or Domain trust issues, you are on your own.

Below is a sampling of the Javascript file for my web application.  It resides in the same folder as the rest of the site code (yes, I know that it could be stored in a sub-folder, but I’m too lazy).  The part to look at is the “winrs” function near the bottom.  But you are certainly welcome to use any other part of it you find useful, as long as you don’t use it in a retail product, and you indicate where you got it, that’s all.

Essentially, the function relies on calling a “winrs.bat” script file residing on the web server.  Think of it like a self-referencing or circular path of sorts.  The web page is rendered in a browser session.  The button click fires an event to execute the “winrs” Javascript function, which attempts to instantiate a COM interface to the “wscript.shell” object class, and invoke its “run()” method to call the winrs.bat file back on the same web host.  That’s a mouthful, huh?

 

cmwtjs

 

Two more considerations come into play now:

  • The browser has to support ActiveX interfacing (pretty much IE)
  • The security has to be adjusted to allow the Javascript request to work (see below)

cmwt_tools2

 

Once that’s done, when you click the button, you should see a security warning pop-up.  When you accept the warning, it should open a CMD shell with WinRS -r:<computer> already invoked.  Easy as, uh, well, sort of easy.

winrs.bat…

@echo off
title Remote Console
winrs -r:%1 cmd.exe

And here’s a chunk of ASP or ASP.NET  code to make the button…

Response.Write "<input type=""button"" name=""b1"" id=""b1"" value=""Command"" onClick=""javascript:winrs('" & cn & "');"" />

or you can define it as inline code within HTML (ASP or ASP.NET Razor approach)…

<input type="button" name="b1" id="b1" value="Command" onClick="javascript:winrs('<%=cn%>');" />

Now you can play with other client “tools” using a web browser.

Reasons for considering a web-hosted client management tool:

  1. You can control access in a central location (rather than dealing with proliferated installed apps and console extensions)
  2. You can log access and session activity to report who did what, to what, where and when.
  3. Code updates are done in one place.  No deployments required.
  4. Having to compile code is rare, if ever.

Enjoy!

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s