This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Best way to Connect to QARS Service? in PowerShell (As quickly as possible)

Hi, 

I'm frustrated by how long it can take to get a usable QARS connection established in my scripts.

The code I have mostly used is:

## Load QARS Module
if ( (Get-PSSnapin -Name Quest.ActiveRoles.ADManagement -ErrorAction SilentlyContinue) -eq $null )
{
  Write-Host "Adding Quest ActiveRoles Module" -foregroundcolor Blue
  Add-PSSnapin Quest.ActiveRoles.ADManagement
}

## Connect to QARS
Write-Host "Attempting to connecting to QADService" -foregroundcolor Blue
try { $connectAttempt = Connect-QADService -proxy }
catch { Write-Host "Connection attempted errored - Please try rerunning script" -ForegroundColor Red
        exit
}
finally { 
    Write-Host "Value of `$connectAttempt is $connectAttempt"
    if ("$connectAttempt" -match "Quest.ActiveRoles.ArsPowerShellSnapIn.Data.ArsServerConnection") {
        Write-Host "Connection attempt appears to have been successful`n" -ForegroundColor DarkGreen
    }
 }

This works, but loading the Snapin takes quite a while.  Whilst searching for a faster way I learned that the Get-PSSnapin syntax is deprecated.  So I have been attempting to load the module using:

Set-Location "C:\Program Files\Quest Software\Management Shell for AD"
Import-Module .\Quest.ActiveRoles.ArsPowerShellSnapIn.dll

This seems much quicker - However when I then attempt to connect to QARS (using same code as in first snippet) the connection can take a long time to establish.

I have failed to find any useful documentation on this - I am happy to read anything people can link me to? 

Alternatively, could anyone share their experiences and or chosen way to manage the load of the module and connect to the service.  I'd really like to find the fastest method I can for this, to include in frequently run scripts.

Thanks in advance,

Andrew

PS Should probably have said the environment I am in uses 6.9.0 I believe (based on install files I used)

  • What are the actual connection times which you are seeing?

    Your cmdlets seem to be perfectly fine. There are no bottlenecks in the code itself which I can see. In my lab, these cmdlets processed in less than two seconds when running on a test machine, and in less than a second when running on the ActiveRoles Server host itself.

    Do you see a significant performance difference between running these cmdlets on your usual machine versus running them on the actual ActiveRoles Server host?

    There are many factors which can impact performance i.e. networking and resource considerations.

    What is the latency between the machine where you are running the connection and the ActiveRoles Server host? What are the resources assigned to the ActiveRoles Server host?
  • There is something to this as I have also seen very long load times in some environments lately when loading the version 7.x powershell component. I believe that it may have something to do with security settings on the box and the rights of the user. To simplify, the tighter the settings / less rights of the user, the longer the load.
  • Thank you very much for your response.

    It is useful to know that my code is valid and can run quickly.

    To clarify - I am interested in the total time from the start of running a script, to being connected. So as I understand it I need to load the snapin\module _and_ then connect. With that in mind...

    Running: Import-Module .\Quest.ActiveRoles.ArsPowerShellSnapIn.dll takes <1 second
    Running: Add-PSSnapin Quest.ActiveRoles.ADManagement takes ~35 seconds

    So looking only at that, I think the choice of which to use would be clear. However what I thought I was observing the other day was that the first command (e.g. Get-QADUser) run after loading and connecting would run in a reasonable time if I had used the Add-PSSnapin, but take a much longer if I had used the Import-Module command. The amount of time felt like it might be approximately as long as the Add-PSSnapin had taken to run. This lead me to wonder whether the module actually only *really* got loaded when the first command that needed to use it was run.

    I have just run some basic tests and Load, Connect & Query for:
    Import-Module ~10 seconds
    Add-PSSnapin ~40 seconds

    That ~10 second result is much faster than I was experiencing the other day, when I was prompted to make my original post.

    In terms of pure connection times, my collected stats over the last 24 hours against the eight version 6.x servers range from 2.08s to 5.31s. Of the eight, two are web something or others.

    I am afraid I don't have local access to the ActiveRoles Server hosts to be able to test performance of Load, Connect & Query on them. Nor do I have sufficient remote access to see what local resources they have. The server I typically use to query from is a VM, 2008R2 4x Xenon E5-2680 @2700MHz & 48Gb RAM. I don't know what kind of contention I might be suffering. It is driven hard with all CPUs typically at 100%. That said it is normally responsive enough to work on. I am just looking for the best way to use what I have.
  • Something crossed my mind - have you tried specifying the FQDN of the ActiveRoles server in your Connect-QAD statement?

    The reason I bring this up is that you may be encountering a bit of latency from the Active Directory side of things as using the -proxy switch alone, a lookup needs to take place in the System Container of AD to find the active ActiveRoles server(s),
  • Have you tried taking the "Import-Module" cmdlet out of your script and inserting into your PowerShell profile?

    10 seconds seems to be reasonable. If you are regularly seeing connection delays in the 40-60 second range, you may want to engage your Active Roles Administrators for a health check.
  • I started off doing this, but of course ran into an issue when that server inevitably encountered a problem. The advice I was given at that time was to just use the -proxy and let the system sort itself out.
    I have created code to test the response time of all servers and then use the fastest, but the benefit of that is lost as soon as it tests a 'bad' server which can then take quite a while to respond or fail or timeout.
    I am happy to accept the AD latency side of things. As I say, so long as I am doing the best I can, that is good enough. I do not have a *need* to get the best possible performance. I would just like to make sure I'm doing things correctly and not running foul of easily avoidable issues.
    Currently it seems that the Add-PSSnapin method is best avoided. Just that still represents a big step forward for me.
  • No, I haven't tried this. To be honest it is not a concept I am familiar with. I think I have read about it. I try to make my QARS scripts 'standalone' as they are often then run from up a number of servers (perhaps a dozen) by any of several admins plus a couple of service accounts.

    If I understand the concept of what you are suggesting correctly, I *think* I would need to configure the PS profile of all the relevant accounts on all the servers.

    If there was a significant performance improvement then it might be worth it, especially for scripts run interactively (ie by people). I am not sure how it would work and whether it would offer any benefit for scripts started by Scheduled Task?

    I do talk to the QARS Admin on a semi regular basis (normally to tell him he has an issue he needs to look at) and the environment did have a virtual hardware uplift at one point which gave a significant improvement (measured).

    If you say 10s is reasonable, then that is good enough for me and a good improvement over the 30-40s I was used to previously.

    One other idea I have had but not tested is that I believe you can do an Import-Module and specify only certain cmdlets to be loaded. I don't know if that is true with QARS or not. However if the module is genuinely only taking 2 seconds to load I can't really expect better than that. If it simply taking 2 seconds to acknowledge the command and then spending 30 seconds in the background actaully doing it, then this concept might have more practical value.
  • Here is a good Microsoft resource:

    blogs.technet.microsoft.com/.../

    If you are working with only a dozen servers, I would certainly recommend testing this to see if you can squeeze a little more performance out of interactive sessions.

    This will also help affect Scheduled Tasks by the same metric, but that is likely not a primary concern.

    Our library is not so large that I think you need to selectively import cmdlets. A selective import is useful with libraries which have hundreds or thousands of cmdlets. I have never encountered a customer who was selectively importing commands instead of simply loading the entire library, so I cannot speak to how that may function in a production environment.