login vsi company logo login vsi company logo 250x40
header-01.jpg

Enabling Remote PoSh for Maintenance with Login AM PowerFlow

Enabling Remote PoSh for Maintenance with Login AM PowerFlow

In the environment of our customer we were experiencing issues with WMI when using the Login AM 2012 maintenance framework (S4Matic). WMI operation on Windows Server 2008R2 has been, to say the least, not great. Microsoft has released a list of hotfixes for different operating systems to fix WMI operation.

Even after applying these hotfixes the problem remained. This was mainly due to multiple programs already doing WMI queries on the machines (RES Workspace Manager and the SCOM Agent). We frequently experienced time-outs when S4Matic performed WMI queries during maintenance. Resulting in machines that were unavailable after the maintenance run or not running maintenance at all.

So we needed to transfer away from the current S4Matic maintenance which uses a lot of WMI queries. To something that relies on a more dependable method of retrieving information and sending commands. That’s where PowerFlow enters the scene. PowerFlow (or Login AM Tasks) is the new maintenance engine that is distributed with Login AM 2012 R2. PowerFlow heavily relies on remote PowerShell to execute commands on remote servers. It still uses WMI for some parts of maintenance (like checking the uptime of a server) but the amount of WMI queries used in PowerFlow is much less.

The first and only challenge with this customer was enabling remote PoSh. This is enabled by default on Windows Server 2008 R2 but it didn’t function. When performing an PoSh invoke-command I’d get the following response:

PS C:\> INVOKE-COMMAND -COMPUTERNAME %COMPUTERNAME% {IPCONFIG}
[%COMPUTERNAME%] CONNECTING TO REMOTE SERVER FAILED WITH THE FOLLOWING ERROR MESSAGE : THE CLIENT CANNOT CONNECT TO THE DESTINATION SPECIFIED IN THE REQUEST. VERIFY THAT THE SERVICE ON THE DESTINATION IS RUNNING AND IS ACCEPTING REQUESTS. CONSULT THE LOGS AND DOCUMENTATION FOR THE WS-MANAGEMENT SERVICE RUNNING ON THE DESTINATION, MOST COMMONLY IIS OR WINRM. IF THE DESTINATION IS THE WINRM SERVICE, RUN THE FOLLOWING COMMAND ON THE DESTINATION TO ANALYZE AND CONFIGURE THE WINRM SERVICE: "WINRM QUICKCONFIG". FOR MORE INFORMATION, SEE THE ABOUT_REMOTE_TROUBLESHOOTING HELP TOPIC.
    + CATEGORYINFO          : OPENERROR: (:) [], PSREMOTINGTRANSPORTEXCEPTION
    + FULLYQUALIFIEDERRORID : PSSESSIONSTATEBROKEN

When you check the remote server Windows Remote Management (or WinRM) is seems to be up and running. However when you check it using the winrm command you get the following:

PS C:\> WINRM QC -Q
WINRM ALREADY IS SET UP TO RECEIVE REQUESTS ON THIS MACHINE.
WSMANFAULT
    MESSAGE = THE WINRM CLIENT CANNOT PROCESS THE REQUEST. IT CANNOT DETERMINE THE CONTENT TYPE OF THE HTTP RESPONSE FROM THE DESTINATION COMPUTER. THE CONTENT TYPE IS ABSENT OR INVALID.
ERROR NUMBER:  -2144108297 0X803380F7
THE WINRM CLIENT CANNOT PROCESS THE REQUEST. IT CANNOT DETERMINE THE CONTENT TYPE OF THE HTTP RESPONSE FROM THE DESTINATION COMPUTER. THE CONTENT TYPE IS ABSENT OR INVALID.

To make a long researching story short. This error has to do with the Kerberos max token size and HTTP max field length. At our customer we had Kerberos max token size of 48.000. This is also the default as of Windows Server 2012 (Microsoft article).

Apparently remote PoSh uses HTTP to communicate with the remote server. I found a Microsoft article regarding to setting the HTTP max field length in correspondence to the Kerberos max token size. Which translates to the following formula:

KerberosTicketSize * 0,75 = HttpMaxFieldLength

I finally settled for these settings:

HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\HTTP\PARAMETERS
DWORD name DWORD value
MaxFieldLength 65534
MaxRequestBytes 65534

I used a regimport in AM2012 to configure the registry settings on the server and a custom actionitem to perform this command: winrm qc –q

After setting the registry settings (reboot needed) and running the command, all my servers responded the remote PoSh commands and I could continue implementing PowerFlow at our customer.

Hope this works for you.

About the author

Sonny Puijk is a R&D Engineer at Login VSI


Tags: How-to, Login AM

Start Delivering the Best End User Experience Today

Request a Demo

Login VSI, Inc.

3945 Freedom Circle
Suite 670
Santa Clara, CA 95054

Phone: +1 408 899 7418

300 Tradecenter
Suite 3460
Woburn, MA 01801

Phone: +1 408 899 7418

Login VSI B.V.

De Entree 85
1101 BH Amsterdam
The Netherlands

Phone: +31 20 705 1200