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

Long winded but interesting outside the box question ..

I've installed both ARS 6.9 and ARS 7 administration services on the same single VM (in our development environment)

This lets me test and easily compare between the two with the smallest virtual footprint.

Since both have different service names, they play well enough together my dev sandbox.

A question came up - about the ARS commandlets.   I didn't update the powershell commandlets - thinking that the newer would supercede or overwrite the 6.9 version.  

Question - When you run a connect-qadservice  - how does/would it know which running service to connect to on the one host?  Do the 6.9 commandlets only connect to 'arssvc', and the 7.0 commandlet versions only connect to 'ARAdminSvc' ?

 

  • The 7.x cmdlets will not connect to a 6.9 service and vice versa.
  • JohnnyQuest to the resQue ... ;)  Thanks man.  Have you had a dual install yourself?  Wondering if there is some trick to install the 7X commandlets without overwriting - or overriding access to the earlier version feature set.

  • I have upgraded environments and dealt with the challenge of multiple cmdlet versions.

    If you are not using the '-proxy' switch, you can continue to use the "old" cmdlets if you like.

    I'm not sure what you mean by the "earlier version feature set" as functionality-wise (6.9 service compatibility notwithstanding), you don't lose anything going with the 7.x cmdlets?
  • I only explicitly installed the commandlet package for 'Quest One ActiveRoles Management Shell for Active Directory x64' 1.7.0.2949 ... yet, when we create a VA in ARS7, and run a get-qaduser username -includedproperties ars7VA ... the commandlet returns the ARS7-only virtual attribute... so I am seeing cross talk despite my best intention.

    The earlier feature set I mentioned - was how the output is formatted by default. ARS7 commandlets improved the information returned without having to weave a powershell script that formats it the way I want. easiest example is get-qarsoperation ... 6.9 concatentated the operationID unless piped to an appropriate format (by default) and 7 expanded it - as it should.
  • (In my opinion) Strategic. Having two ARS (different versions) on the same server is very unpractical idea. No sure what was the reasoning of the product architect designed the feature. ARS is a *mission critical for compliance* app / HA, and to introduce dependency of change control on ARS 6.x because update of ARS 7.x, and vice versa downs the road from 6.x to 7.x - it is a very unrealistic and unpractical scenarios. All ARS upgrades I do is in-parallel, not in-place because of mission critical factor.
    Technical. ARS MMC can connect to the same version of Admin Service only. I expect this must be valid for cmdlets (as supported and tested scenario)
  • This is a dev ... crash and burn environment. There is nothing mission critical here - merely a place to try and fail. The final outcome of my testing this morning - with a fellow admin, is that while - I was able to see the separation ... I could only read attributes specific to 6.9 from the get-qaduser command at an administrator launched powershell 4 console, my co-worker was able to only see attributes specific to 7.0 - same server - parallel instances, where he was using the venerable, but tired PowerGUI. I believe the issue we were running in to was one of pathing. I installed ARS7 - he consumed it. My module path and his are assumed to have been different. I uninstalled ARS7 a few minutes ago from this host and restarted -leaving only ARS 6.9 instance in place.
    He can now only see ARS 6.9 related attributes, and my view hasn't changed. I still only see 6.9. It was a good exercise.

    I ask the best questions - in like - ever. ;)