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.
