HPE Insight Remote Support fails to start after reboot

We utilize HPE Insight Remote Support (IRS) at all our client sites, and typically have it running on either Windows 2008 R2 or Windows 2012 R2.  To simplify administration, we typically enable auto-update of IRS, which means IRS will download updates from HPE as they become available and self-update.  One of the lovely “features” that we discovered is that upon the next Windows server reboot after an IRS update (typically at 3am on the first Wednesday after the 2nd Tuesday of every month – thanks Microsoft), the HPRSMain service fails to start.  No amount poking, prodding or swearing will convince the service to start either.

The solution is to run a repair – except the HPE team doesn’t make that easy either as the only option in Add/Remove programs is to uninstall.  Fortunately, you should find the .msi for IRS in C:\ProgramData\HP\RS\DATA\SWM\LANDINGZONE\ProdUpgPkg\unzipped\lib.

So the quickest way to fix IRS at this point is to open an Administrative Command Prompt and run:

msiexec /f "C:\ProgramData\HP\RS\DATA\SWM\LANDINGZONE\ProdUpgPkg\unzipped\lib\hprs7kit.msi" /lv "%HP_RS_LOG%\hprs_recovery.log"

After a few minutes, the HPRSMain service should start and good until at least the next IRS update.

Windows 2012 R2 is unable to connect to HP StoreOnce CIFS shares

I ran into this issue the other day with a new HPE StoreOnce deployment. When attempting to connect to a CIFS share on a StoreOnce appliance (it does matter if it is physical appliance or VSA) from a Windows 2012 R2 server, the following error is received “The account is not authorized to log in from this station”.

1

To fix this, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters and set RequireSecuritySignature = 0  and then reboot Windows.  When Windows comes back up, you should now be able to browse the CIFS share on the StoreOnce appliance.

2

HOWTO: Generate and self-sign Wildcard SSL certs in Ubuntu

Generate a CSR:

openssl req -new -newkey rsa:2048 -nodes -sha256 -out wildcard.domain.fqdn.csr -keyout wildcard.domain.fqdn.key -subj "/C=your_country/ST=your_state/L=your_city/O=your_organization/CN=*.domain.fqdn"

View the CSR:

openssl req -text -in wildcard.domain.fqdn.csr

Sign the certificate:

openssl ca -in wildcard.domain.fqdn.csr -out wildcard.domain.fqdn.cer -config /path/to/openssl.cnf

Convert the certificate to PFX:

openssl pkcs12 -export -out wildcard.domain.fqdn.pfx -inkey wildcard.domain.fqdn.key -in wildcard.domain.fqdn.cer

Covert the certificate to PEM:

openssl pkcs12 -in wildcard.domain.fqdn.pfx -out wildcard.domain.fqdn.pem -nodes

HOWTO: Schedule Daily Netscaler VPX Reboots via Powershell

We often utilize Citrix’s NetScaler VPX running on VMware ESXi 5.5 to allow our clients to securely connect to their Citrix infrastructure from outside the firewall.  For the most part – it works well.  Unfortunately though, our experience has taught us that occasionally NSVPX goes all fubar on it’s own after a few days of running and stops processing connection requests once the user logs in.  A simple reboot of the NSVPX VM usually resolves the user’s connectivity issues..

To combat this issue, I wrote a Powershell script that we run as a daily scheduled task on our management server to have vCenter automatically restart the machine once a day.  You could easily modify this script to reboot any VM you want though.

To configure daily VM rebooting, the current VMware PowerCLI client needs to be installed on the machine that will be running the scheduled reboot.  Once the VMware PowerCLI is installed, you need to create 3 files on the management machine:

  1. daily_nsvpx_reboot.cmd – which is the wrapper that will call PowerShell from TaskScheduler (see below in for cut and paste of the file contents)
  2. daily_nsvpx_reboot.ps1 – which is the actual PowerShell script that executes the reboot (see below for cut and paste of the file contents)
  3. daily_nsvpx_reboot.pwd – which is an encrypted file that contains the vCenter user’s password

To create the file daily_nsvpx_reboot.pwd, open PowerShell and run the following command:

read-host -assecurestring "Enter Password" | convertfrom-securestring | out-file c:\windows\daily_nsvpx_reboot.pwd

At the “Enter Password” prompt, enter the password of the user account you will be using that has rights in vCenter or the ESXi host to perform VM restarts.

You may also need to set the PowerShell Execution Policy to support remote signed scripts such as daily_nsvpx_reboot.ps1.  To do this, open PowerShell and run the following command and select Yes when prompted:

Set-ExecutionPolicy RemoteSigned

After creating daily_nsvpx_reboot.cmd and daily_nsvpx_reboot.ps1 (see below for file contents of these two files), edit daily_nsvpx_reboot.ps1 and adjust the variables for $server, $user, and $vm2reboot to fit your environment (these three variables are all defined at the top of the script).

Lastly, you need to schedule daily_nsvpx_reboot.cmd to run daily.  I’ve set 4:15 am local time in the example shown below, but you can adjust as required.  To schedule the task, open an Administrative command prompt and run the following command (adjust domain\username to be the same user account that has rights in vCenter or the ESXi host to perform VM restarts):

schtasks /create /tn "Daily NSVPX Reboot" /tr C:\WINDOWS\DAILY_NSVPX_REBOOT.CMD /sc daily /st 04:15:00 /rp "*" /ru "domain\username"

All that is left do now is test run daily_nsvpx_reboot.cmd and see that it runs and reboots the NSVPX.  If you are monitoring via ProcExp or TaskManager on the management machine, you should note low CPU usage followed by several spikes up to 50% (it is single threaded), and you should be able to see in the NSVPX console via vCenter when it reboots.

And as always – Use any tips, tricks, or scripts I post at your own risk.


daily_nsvpx_reboot.cmd – file contents

rem — begin cut and paste of notepad c:\windows\daily_nsvpx_reboot.cmd
@echo off
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy RemoteSigned -noprofile -File C:\Windows\daily_nsvpx_reboot.ps1
exit /b
rem — end cut and paste of c:\windows\daily_nsvpx_reboot.cmd —

daily_nsvpx_reboot.ps1 – file contents

    ###— begin cut and paste of notepad c:\windows\daily_nsvpx_reboot.ps1

    ### Daily_nsvpx_reboot.ps1
    ### @deancolpitts – http://blog.jbgeek.net
    ### 2015.01.02
    ### This script will attempt to perform a graceful VM restart via the VMware Tools inside the guest.

    ### Variables – please only adjust server, user, and vm2reboot.  Any other variables should not be touched.
    ### Server is the vCenter server or ESXi host’s FQDN, while user is the vCenter user or ESXi user account.
    ### if any smtp variables present, they should be self-explanatory.

    $server = “vcenter.domain.fqdn”
    $user = “vcenter_username”
    $vm2reboot = “nsvpx”

    ### Read the encrypted user password from “c:\windows\daily_nsvpx_reboot.pwd”
    ### Use the following commented out PowerShell command to manually create a new credentials store.
    ### Enter the user’s password when prompted while running the read-host command
    ### read-host -assecurestring “Enter Password” | convertfrom-securestring | out-file c:\windows\daily_nsvpx_reboot.pwd

    $credentialFile = “c:\windows\daily_nsvpx_reboot.pwd”
    $pass = cat $credentialFile | convertto-securestring
    $credentials = new-object -typename System.Management.Automation.PSCredential -argumentlist $user,$pass

    add-pssnapin VMware.VimAutomation.Core -ErrorAction SilentlyContinue -WarningAction SilentlyContinue | Out-Null

    if ( $DefaultVIServers.Length -lt 1 )
    {
    Connect-VIServer -Server $server -Protocol https -credential $credentials -WarningAction SilentlyContinue | Out-Null
    }

    Restart-VM -VM $vm2reboot -RunAsync -Confirm:$false

    ###— end cut and paste of c:\windows\daily_nsvpx_reboot.ps1 —

HOWTO: Make a 3Par RJ45 serial console cable for an OpenGear ACM5004 Remote Site Manager

On all the 3Par StoreServ 7000/8000 nodes we manage for our clients, we utilize OpenGear ACM5004-F-E Remote Site Manager (basically a serial console switch) so that we can remotely access the serial console on the nodes (in case a node is shutdown to the SMI Whack prompt or something else silly is going on).  The ACM5004 has 4 x RJ45 serial ports on it, which are a Cisco Straight pinout.

Just plugging a standard patch cable into the ACM5004 and the back on the StoreServ node isn’t going to work.  And using the RJ45/DB9 couplers that the 3Par ships with is both a pain in the butt, an eye sore, and bulky.  So I set out to build my own custom RJ45 cable.

On the 3Par end, use pins 2 (orange), pin 3 (blue), and pin 5 (green). Be sure to label this end as the 3Par end!!! I attempt to always put a small tiewrap (which is white in the photo below and hard to see thanks to a blurry photo) around this end of the cable to mark it as the 3Par 3nd.

On the ACM5004 end, use pins 3 (blue), pin 5 (green), and pin 6 (orange). Be sure to label this end as ACM5004!!!

Plug the 3Par end into the node’s serial console port, and the other end into the ACM5004.  After configuring the ACM5004, SSH it and connect the appropriate port on the ACM5004 and you should now see your 3Par serial console.

3Par
3Par End
ACM5004
ACM5004 End

HOWTO: Remotely log off an ICA / RDP session

Occasionally, folks on my support team will accidentally disconnect from an ICA session at a client location, and I’ll need to log into that same server via RDP with our shared support account and can’t due to the disconnected ICA session.  Rather than taking the time to log into StoreFront, and reconnect to that disconnected session, the quickest thing to do is log it off.  Here is a pretty simple two liner you can run against a remote server to enumerate the user sessions and log a session off.

In an administrative command prompt run:

query session username /server:servername           (where username is the user you want to log off and servername is the server they are logged into, or skip username to show everyone logged in)

Query will return the sessionname, ID, and state of the user’s connection.  To log the user off, run:

logoff ID /server:servername           (where ID is the ID of the session from the previous command of the user you want to log off and servername is the server they are logged into)

logoff