I would't be so drastic, *.docx is still a universal format that remain to be challenged. Another workaround is to disable some auto-correct features in Word like double-dash, upper case in 1st word etc. Or even use the [Ctrl+Z] shortcut to cancel the unwanted corrections on the fly. ... View more

Your post is illegible : _ could you, please, edit the message once again and add some meaningful indentation and/or typo signs into the different lines / tree "branches" ? Frankly, I am not sure anyone will ever try to decipher your text with this kind of ultra minimal editing... HTH Ronan ... View more

I agree with @JuanS_OCS , Metacoda SMC plug-in for Roles & capabilities is a must-have tool.   As pointed out by @nhvdwalt above, defining the scope of access to SAS software, to any software more generally is sometimes tricky because there is not a single definition that applies, from broad to narrower :   1. "Local Installation" [in the case of desktop tools] the software is installed locally on the users PC and ready to be used    => Check with your Desktop Admin team to retrieve the list of installations   2. "Authorization" : the user is authorized by the SAS Administrator to run the SAS client   => Use Metacoda SMC Plug-In mentioned by @JuanS_OCS   3. "Effective Usage" : the user has already used at least once the SAS client   => Use SAS platform Audit reports and maybe soon, some Metacoda extended features 😉   The three scopes are never identical, at least in the real world I know 🙂   In terms of contract between the user's company and SAS, as far as I know, the 1st definition applies. Then internally, the company/service might have set up deployment quotas  to further restrict the access. Eventually, some security rule at the Directory level (AD) might also apply : an unused account is automatically revoked for instance if no access has been performed during a certain amont of time etc.     ... View more

Ok, I see, thanks for clarifying. You are trying to declare some hidden libraries based on Windows shared folders for specific users. As @Kurt_Bremser mentioned, its quite difficult to declare something *and* to keep it undeclared : you have to choose either way, not both in our coarse euclidean universe ! (at smaller scale, someone has told some time ago, things might different 😉 )   For this kind of purpose, you can of course let the user assign manually the library in her/his session as shown above.   You can also use indirect libraries assignments based on System environment variable, here Windows folder paths (I assume) :   http://documentation.sas.com/?cdcId=pgmsascdc&cdcVersion=9.4_3.2&docsetId=hostwin&docsetTarget=n07buc7sg08fdrn1c1jmmr8hl78r.htm&locale=en   Assuming you declare at the OS session level some "LSENS" (name it as you like following SAS libname namings rules) environment variable like   LSENS=Z:\SENSITIVE_DIRECTORY_PATH   then, in the SAS session, your SAS user can access any SAS tables stored in this directory without any prior explicit libname assignment.    Running a sas code like this one will automatically assign LSENS libref the first time it is encountered :   data LSENS.mytable; set source_table; run; ... View more

If I understand correctly what you are looking for, viz trying to select an autoexec conditionnaly based upon some user's attribute in metadata, I think it won't work that way. Auhentication domains are no placeholders for tagging users, they're technical artifacts for streamlining authentication processes (for instance : users authenticating with their AD account/pwd, generic DBMS accounts like Oracle authenticating against some LDAP directory etc.). Description field can be reused, but as @Damo has shown, it requires (costly) custom requests in metadata because this information is not presented by default when a SAS session is launched.   If you try to follow the standard SAS 9  guidelines, you might have to create new objects instead,namely   1) a second Workspace Server references in Metadata (Plug-in Server Manager) 2) the corresponding Configuration directory, which comes with some customisable Autoexecs 3) a second metadata Group  3 4)  some ACTs to redirect users  groups to the first Wk Server or to the 2nd based on their MD group   If you want to spare some extra directories, 2) is not even required sometimes.   With this, the user launches the autoexec conditionnaly without having to devise some custom MD request & custom parameter storage within a user's MD references : this is automatically handled by metadata standard security rules. ... View more

UPDATE   Availability confirmed 26th, September ... View more

Using the information provided above by @alexal and the SMC, Server plug-in monitoring feature, you can retrieve the information and join manually SAS Session PID and Work path :   https://support.sas.com/documentation/cdl/en/bisag/68240/HTML/default/viewer.htm#p0o497lmygjfrfn0z7t999n72tpg.htm   Automating this join shouldn't be unfeasible either :   https://blogs.sas.com/content/sasdummy/2016/02/15/using-proc-iomoperate/       ... View more