Jump to content
Welcome to our new Citrix community!
  • 0

XenMobileShell New-XMSession call immediately times out session, returns invalid Auth Key


Nicholas schneider

Question

Hello,

I am trying to use PowerShell to send commands to XenMobile and pull data for the users that are currently inactive for over 30 days. I am using PowerShell V5.0 and have the XenMobileShell module installed on the machine. When using the built in function to create a new session, I am able to create a session with the credentials I added; however, when I go to make another call, that session has already expired, meaning that I can no longer make any other calls using the Authentication token I am receiving. 

 

Here is an example of the code I am trying to run:

 

##### Variables #####

$loginServer = "URL Placeholder"
$loginPort = "Port Placeholder"

$loginUsername = "Username Placeholder"
$loginPassword = "Password Placeholder"

$XMSAuthtoken = ""

##### Variables #####

##### Functions #####
#This function uses the 
Function Start_Session()
{

    $XMSAuthtoken = new-XMSession -user $loginUsername -password $loginPassword -server $loginServer -port $loginPort

    #Return $XMSAuthtoken
}
#
Function Get_XenMobile_Device_Filtered()
{
    
    $deviceList = get-XMDevice -filter "[device.inactive.time.more.than.30.days]"
    
    Return $deviceList
}
#This function takes a device ID and removed it from the XMS server and Database
Function Remove_XenMobile_Device()
{
    Param([string]$deviceId)
    
    Remove_XenMobile_Device $deviceId
    
}
##### Functions #####

Start_Session

$deviceListFiltered = Get_XenMobile_Device_Filtered

write-output $deviceListFiltered

 

This should, in theory, connect to a new session, grab all of the devices that are inactive for 30 days, and print those to the screen. What is does is attached as a screenshot in the attachments section. 

 

If anyone has worked with PowerShell and the XenMobileShell module, let me know if there is something I am doing wrong. 

 

Thanks,

Nick 

PowerShell_XenMobile_Session_Error.png

Link to comment

8 answers to this question

Recommended Posts

  • 2

Hi Nick,

The XenMobileShell module is not officially supported by Citrix, but I took a look. I have found the issue and have a fix, but please consider this as my personal help and it is not formal support.

 

I am able to reproduce the issue, and this is the behavior before my change with your script:

PS C:\DevTrees\XenMobileShell> get-date
Thursday, November 29, 2018 4:53:21 PM

PS C:\DevTrees\XenMobileShell> .\Audit.ps1
Authentication successfull. Token: mZ62+u8smoy6kD/Ny1x0cAnJ:4ff1506e553506508f5
Session will expire at: 11/29/2018 16:52:58
Session has expired. Please create a new XMSession using the new-XMSession command.

This is the behavior after my change:

PS C:\DevTrees\XenMobileShell> get-date
Thursday, November 29, 2018 4:45:43 PM

PS C:\DevTrees\XenMobileShell> .\Audit.ps1
Authentication successfull. Token: 4EKvlENWhG+prLBuT53y8/js:7d644fe896ca03daf
Session will expire at: 11/29/2018 17:45:16

id                  : 29
jailBroken          : False
managed             : False
gatewayBlocked      : False
deployFailed        : 0

... snip ...

The issue is that the XenMobileShell module queries some server properties after login in order to discover what the timeout value is. In cloud-hosted environments these server properties are controlled by our Citrix and are not visible to customers.  Therefore the timeout values cannot be read, and are evaluated as zero or false. The session is actually valid, but the XenMobileShell believes incorrectly that the timer has already expired.

 

This is the code that has the problem:

        #get the static timeout and deduct 30 seconds.
        $timeToExpiry = ([convert]::ToInt32((get-XMServerProperty -name "xms.publicapi.static.timeout" -skipCheck $true).value))* 60 - 30

This is my proposed fix:

        # Get the static timeout and deduct 30 seconds. 
        # Note that for cloud-hosted sites this setting is not visible to the customer, and will evaluate to 0.
        $staticTimeout = [convert]::ToInt32((get-XMServerProperty -name "xms.publicapi.static.timeout" -skipCheck $true).value)
        if ($staticTimeout -eq 0) {
            $staticTimeout = 60
        }
        $timeToExpiry = ($staticTimeout)* 60 - 30

I've tried to create a Pull Request in github so that I can submit this fix at the source (https://github.com/wvanbesien/XenMobileShell), but I don't have permission to create a new branch and create a PR.  I'll try and reach out to the author.

  • Like 3
Link to comment
  • 0

This might be because you're calling up separate functions, so it's basically running two different scripts without passing anything between them. Try putting your device list query into the first function that sets up the xmsession. So:

 

Function Start_Session()
{

    $XMSAuthtoken = new-XMSession -user $loginUsername -password $loginPassword -server $loginServer -port $loginPort

    #Return $XMSAuthtoken

 

    $deviceList = get-XMDevice -filter "[device.inactive.time.more.than.30.days]"
    Return $deviceList
}
 

We've been using the XenMobile PowerShell Module for about a year now to run cleanup and exports, so we have some experience with it if you have other questions.

Link to comment
  • 0

Hey Ryan,

 

Thank you for the response. I have made $XMSAuthtoken a global, so the module should be able to access the variable when it makes its call, regardless of which function that call starts in. 

I updated my script to be a simple version without functions for testing now, and have added (Get-Date) tags to show that the session being created expires 30 seconds before the command is even run. 

 

Do you think it is an issue with the type of account I am using to authenticate? That maybe it has the permissions to create a token, but not the permissions to create a token that doesn't time out instantly?

 

I found someone with a similar issue say that this is what they did to fix the issue; however, the only option I have not tried is checking the local account settings via citrix

******

I ran into the new session issue as well. I was able to fix it using several articles. Here is a summary of what I did to fix the issue. 
1. Be sure to use a local XM user account. 
2. To use the Get-credential procedure (mentioned in another article but is very useful for hiding your userid and password) make the local XM user account and password the same as your AD user & password and it will perform a kind of pass-thru auth. 
3. Also, be sure to use the fqdn not the IP address. Of course you will need the DNS A records or update your local host file.
That's it.

******

 

**************************************************************

$loginServer = "FQDN Placeholder"
$loginPort = "Port Placeholder"

$loginUsername = "Username Placeholder"
$loginPassword = "Password Placeholder"

$XMSAuthtoken = ""

 

Write-Output "Start New-XMSession call"
Write-Output (Get-Date)
$XMSAuthtoken = new-XMSession -user $loginUsername -password $loginPassword -server $loginServer -port $loginPort
Write-Output "End New-XMSEssion call / Start Get-XMDevice Call"
Write-Output (Get-Date)
$deviceList = get-XMDevice -filter "[device.inactive.time.more.than.30.days]"
Write-Output "End Get-XMDevice Call"
Write-Output (Get-Date)
Write-Output $deviceList

**************************************************************

SessionInstance.png

Link to comment
  • 0

We do use a local account on the XenMobile server that has ADMIN rights (requirement if it's going to access port 4443). Also note that the XenMobile PowerShell Module has the port built into the 'new-XMSession', so you shouldn't have to specify the port. The FQDN is also important and you must have a trusted certificate on the XenMobile server (so publicly signed) for the script to work.

 

But you're already getting a token so you're passing all of those things fine anyways from what I can see. The weird part is that the token is set to expire 30 seconds prior to its creation. Does the XenMobile Server have the correct date/time specified in the console?

Link to comment
  • 0

Terry,

 

This is fairly similar to the fix I implemented. It is nice to know the reason why that call was broken, as I had just assumed Citrix had updated the name of the value, not that it simply wasn't visible to us. 

 

Are there any plans in the future to have this changed to a variable that's visible to cloud based users? 

 

Thanks,

Nicholas Schneider  

Link to comment
  • 0

So we just moved XenMobile to the Citrix Cloud, and I'm running into the same issue as Nick. The fix Terry provided doesn't work for me unfortunately. Now I'm debating rewriting my scripts to use the standard REST API rather than PowerShell ...Nick, did you get this working?

 

EDIT: Nevermind, I got it working...reload your modules after making the change...

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...