Fun Fact: EDMS:// is to ARS as LDAP:// (or GC://) is to Active Directory

If your organization is anything like mine, you would have a rebellion on your hands if you said that you were taking native AD privileges away, and that any old scripts that relied on ADSI wouldn’t work anymore, but, hey, look – PowerShell awesomeness in the Quest Active Directory Management Shell!

Yeah. Don’t do that. There’s no reason to – ARS has an ADSI provider that works enough like the native AD one that it can be used pretty much the same way.

Here’s a peace offering to accompany the announcement that native AD privileges will be a thing of the past: they can simply do a find on LDAP://whateverserver and replace it with EDMS://yourARSloadbalancer. If their scripts have it in the form of LDAP://distinguishednameonly, it’s simply a matter of replacing LDAP:// with EDMS://. Same with GC:// (uses a global catalog server instead of any old domain controller like LDAP:// will) – just replace it with EDMS://.

I can’t guarantee that this will work 100% of the time, but my colleagues who have tried it report that it has for them, and they are heartily grateful that I’m not making them learn PowerShell yet.

Make sure the script is run on a machine with the ADSI provider for the correct version of ARS installed. Which is installed when you install the Quest AD Management Shell. Which they might later discover is awesome for quick things they used to write nasty VBScripts for.

Related Fun Fact: if you know the DN of an object, referring to it by [adsi]"EDMS://distinguishedname" is usually WAY faster than Get-QADObject -Identity distinguishedname. In my environment, from the interactive shell in PowerGUI, the ADSI way consistently takes less than 0.1 ms, while the nifty cmdlet way takes about 150 ms (YIKES!). The convenience of QAD cmdlets has its price. For command-line one-offs, though, they’re a whole lot of wonderful.

Advertisements

2 thoughts on “Fun Fact: EDMS:// is to ARS as LDAP:// (or GC://) is to Active Directory

  1. Hi!
    This is not always true

    I’m trying to connect to our AD through ARS using a VBScript.

    I t works using “EDMS://OU=……” But If I try to set the Domain Controller Host to connect to an specific server, it did’nt work.

    “EDMS://hostdomain.domain.intra/OU=…”

    I got this error on that scrip line:
    create_groups_12_76.vbs(42, 1) (null): 0x80041455

    Like

    • Hi Julian,

      Thanks for making a point I didn’t think about: if the domain controller or even domain is referred to at the beginning of the URI, it won’t work, because the domain controller is not running the ARS service. Referring to a specific ActiveRoles Server should work, however.

      Quick way to remedy this: remove those references, and trust ARS to find the right domain – you’ve got that info in the distinguished name you’re passing.

      Best regards,

      Amanda

      Like

Write your own memo:

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s