Cannot connect to ARS using Connect-QADService when called from a PowerShell Module

We have a basic script that opens a connection to ARS from within our PowerShell scripts. The script was provided by our Active Directory team and basically searches for ARS SCPs in AD, gets a list of those connection points, extracts the ARS server names and then attempts to connect to ARS using Connect-QADService -Proxy cmdlet. If the connection fails the script tries the next available ARS server and so on.

Our AD team are now telling us that we have to upgrade from ARS 6.9 to 7x and have found that the server names listed in AD SCP records have changed from being listed in the Name property in ARS 6.9 to the serviceDNSname property in ARS 7. This necessitates modifying 50+ scripts which currently reference the name property, which is a big pain!

To overcome this (and to position us for future changes), I've been working to develop a custom PowerShell module which contains a function called "Connect-ARS". In that function is all of the code to get the ARS SCPs from AD and then try to connect to ARS using Connect-QADService. My idea is that I could then replace the manual connection code in each of our scripts with a simple call to the Connect-ARS function (which is stored in the custom module)… that way, when the time comes to upgrade to ARS 7, I only need to change the connection code in the custom PowerShell module, instead of in each script. Unfortunately it does not work because it appears that the Connect-QADService cmdlet only creates the connection to ARS in the scope of the PowerShell module/function that calls it. Once control is handed back to the calling PowerShell script the connection to ARS is no longer active (as validated by running Get-QADRootDSE) and any Set-QAD cmdlets fail with "Access is denied" error. I also tried dot-sourcing the code that calls Connect-QADService instead of using a Module, but I saw the same problem.

Is there’s any work-around to ensure the ARS session/connection created by the Connect-QADService cmdlet remains valid once control is handed back to the calling script? I believe this is a PowerShell scope issue. Similar issues occur when importing remote PSSessions from a function stored within a module but there's a workaround in this case - use Import-Module (Import-PSSession) and set the scope of the module to -Global so that it remains in-scope. Unfortunately Connect-QADService doesn't have a scope parameter so there's no obvious way to overcome as far as I can tell. I'd really appreciate any other suggestions or thoughts.

I can provide code samples if it would help.

  • So when you are making your call to your connect function, are you saving the session in a variable?

    $MyARSession = Connect-ARS

    Get-QADUser -Connection $MyARSession -identity JBlogs
  • What value from the SCP's 'name' attribute do your scripts written for ARS 6.9 currently expect to see? I don't have 6.9 installed at the moment, but I can say that in version 7.2.1 the 'name' attribute on the SCP is populated with '<servername.fqdn>:port'. Is this different from what the scripts are currently coded to handle?

  • In reply to JohnnyQuest:

    Thanks. My function was saving the ARS session and storing it in a variable but I didn't know about the -Connection parameter. I tried it and it works! Thanks so much for the speedy response.
  • In reply to Richard.Lambert:

    @Richard.Lambert

    Yes, it is different. So under ARS 6.9 the SCP records show the servername under the 'Name' property:

    Name

    Server1.QA.myco.com

    Server2.QA.myco.com

    However under ARS 7 the SCP records still contain the 'Name' property but the value of the server is prepended with ':17228'. And the whilst it looks like a port number it is not the port that our instance of ARS is using (according to our AD team). In addition there's a new property called 'ServiceDNSName' which just contains the servername: 

    Name                      ServiceDNSName

     

    Server1.QA.myco.com:17228 Server1.QA.myco.com

    Server2.QA.myco.com:17228 Server2.QA.myco.com

     

    So either we have to adjust the code to programmatically remove the ':17228' or we have to start using the 'ServiceDNSname' instead.