How to Use Windows Batch Files and PsExec to Push Files and Actions to Remote Machines

I work in a casino. As I live in Las Vegas, this isn't uncommon. I won't divulge any specific information about where I work or any important details about where I work for, I hope, obvious reasons. Not that it's hard to find out who and where I work since this blog is published under my real name. This is about how I accomplished a large feat using minimal skills/effort earlier this year. It's a bit convoluted but it accomplishes the task fairly well, if not a bit slowly due to sheer volume. I'm not sure if PowerShell could've accomplished this better.

It was December 27th, 2012. The vice president of marketing came up to my boss, the vice president of IT. Scattered around the property there are 150+ displays showing marketing content. Glorified PowerPoint presentations, if you will. Well, the VP of Marketing wanted us to update all the content on every single one of those displays. He didn't care how just that it got it done and by January 1st. To me and my team, it was a ridiculous deadline. We didn't think it could be done with the solutions we had in the time that he wanted.

The machines are Paltronics media controller boxes and none of them are on our domain nor do we have a Paltronics media server since that was removed by the previous owners prior to the transition to the new owners. As we found out, they're just really old Windows XPe machines. The specs on them were something straight out of 2004 - Windows XPe SP2, first gen P4, 196MB of RAM, 40GB HDD (split into two partitions), and a S3 on-board video card. They were setup to to auto-login using the local administrator account and a generic password hiding in plain text at the registry key below (we had a couple spares laying around):

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]

Having this in plain text was a small step towards resolving the issue. It meant we could remote in and update the machines ourselves. Wrong, the flimsy Windows Firewall was turned on which disallows ICMP as well as any kind of inbound traffic unless defined in the exceptions. Seeing as we had a spreadsheet with 99% of the boxes' IPs, I went through and pinged them all. It went quick since they're all in the same subnet and none responded to pings.

So while a couple other members of my team went to the various communications closets and places where the boxes are located to turn off the Firewall, I was wracking my brain on how to be able to push a handful of files to each of these machines. When one of my team members came back, he mentioned something called PsExec that might be able to help since he'd used it in the past to push a file from his computer to a server he was working on at his last job. He didn't know if it could be used to do multiple computers at once, though.

A little background on the Paltronics boxes. The main Paltronics media server for the content to be pushed from using the Paltronics software was no longer available to us. All of the controllers were running in standalone mode showing the content from when the last time the media server pushed content to them. The Paltronics boxes use XML files for configuring where and what content to display. There's an XML file for using which "channel" to display (ChannelListing.xml). In the XML file you can configure which channels are enabled and the program will look for an XML file using that channel number as its name, for example 802.xml. After seeing the syntax of the XML, it was a fairly quick process of updating it to point to the new files in the right directory structure for the program to see. To navigate between channels while the program is running just press CTRL + Shift + Up/Down and it will cycle between the enabled channels. The XML file makes a call to a a script called "PlayDirectoryKiosk" so you only have to use local file names, without the directory paths.

Inside the code block you can repeat the AlertWindow and WaitDuration tags for, what seems, as many files as you'd like to display. In the screenshot, I show only two but we've used up to 10 so far without issue. There is also support for MPEG-2 video and JPEG images.

I Googled PsExec at the suggestion of a coworker since he'd used it before but for other functions and found the download page on TechNet. I promptly dropped the files into System32 so they'd be in my system's PATH without having to add anything. I went to the trusty site SS64 to find out the syntax on PsExec commands. After looking through it, I quickly realized it could be used to blast out and execute a batch file on remote machines. If a display's screen is vertical, the images will need to be rotated 90 degrees since the S3 cards on the machines don't support rotation (as far as I could find in the controls). If it's horizontal, landscape is the default orientation. It's easier to make a folder for each orientation with the required modified files. PsExec supprots using UNC path names but I opted to use the IP since sometimes UNC pathing can break and the hostnames for these things are really off-the-wall but are all on the same subnet.

PsExec batch file (assuming PSTools executables are in the executing computer's, not the remote computer's, PATH):

psexec \\ip_address_or_hostname -c -f -u local_administrator_account -p Local_administrator_password \\server\share\Copy.bat

Batch file that runs on the machine PsExec pushes the file (portrait is used for example):

net stop launchservice
net use z: \\server\share /user:domain\user password /persistent:no
copy /Y "Z:\Portrait\image1.bmp" "D:\Signroot\Content\image1.bmp"
copy /Y "Z:\Portrait\Channel802.xml" "D:\Signroot\scriptFiles\Channel802.xml"
net use z: /delete /Y
net start launchservice

In the PsExec batch file, it connects to the machine using the local admin account then copies the batch file that does all the work over then runs it. The work batch file stops the player service, maps a network drive to the share with the files, copies the files over to the proper directories on the Paltronics device, closes the network drive mapped earlier, and finally starts the service back up. Provided everything copied over just fine and the service launches, the new content will start displaying.

Using all of the above, my coworker and I were able to create a set massive of PsExec batch files that did the same thing across all of the Paltronics devices, portrait and landscape. As we were successful, we shifted focus to automating the process.

On one of our department servers, we setup a series of scheduled tasks for each day of the week (these are easy to setup and I won't go over the specifics). There's a task for portrait and landscape orientations as well as backup, and copying to live from staging for each day. On the file server, we created a hierarchy of folders - config, live, backup, and staging. Config holds 10 folder, numbered 1-10 with the Channel XML file setup for x amount of images based on the folder number. Live is what's currently being displayed. Backup is a backup of the live folder. Staging is where the person the marketing department drops the config file and the images to be copied to the live folder. Inside the staging folder are folders for each day of the week.

At 11:30pm every day, a task executes a batch file that copies the files from the live folder to the backup folder. At 11:50pm every day, a task executes based on what the next day is and copies the files from that staging day folder to the live folder. At midnight every day, a couple of tasks execute that copies the files in the live folder out to the respective orientations (portrait and landscape).

After a round of testing for both orientations, we trained marketing on how to setup the images (resolution and rotation for portrait) and work with the staging and config folders (they only have read access to the live and backup folders for hopefully obvious reasons).

After all that, BOOM! we have complete control of the Paltronics media controllers without the ridiculously expensive (~400k quoted) costs of buying completely new hardware and media servers since the ones we have are a bit on the old side. This solution has been in place for several months now with nary a hiccup. The only issue that is sometimes ran into is that the service will not properly relaunch, which is a simple fix. We'll be moving to newer, better hardware in the next year or so from a different vendor at a much lower cost but same function.

Popular posts from this blog

Faculty Senate votes ‘no confidence’ in three vice presidents (News)

Let's talk about OUYA

How I got into the world of IT and where I'm going