Hi SAS_Ebad. It sounds like you are hitting an issue where the configuration code fails when the user id specified already exists in metadata. In your case I see the following in the log: [GetObjectProperties] oma.person.demo.login.userid=SAS2\sasdemo This means the login is already defined in metadata and cannot be redefined to also exist on another user (or as a login on a group). Later I see the script trying to add this id to the Marketing Automation Scheduling Users group: Replacing: @login.name@ -> Login.MASchedulingUser.86 Replacing: @login.passwd@ -> <removed> Replacing: @login.userid@ -> SAS2\sasdemo Replacing: @repository.foundation.name@ -> Foundation I could go into the gory details of why the deployment process does not prevent you from reusing a login, e.g. the same login can be used with again on the same user, but with a different authentication domain is among one of them, but the long and short is that when you are prompted for an account/login to use for a specific task that login should not already exist in metadata. There is information about this in the checklist that ships with the plan file you are using, but your release of SAS 9.3 might be too old to contain that information. ... View more

Hi robm. I've not worked extensively with the undeploy and redeploy commands, but I know a little about the middle tier deployment that may help you understand the doc a bit better. First in the doc you reference if you go to the topic  Scripting Tool for SAS Web Application Server you will see that it references a file called appserver.properties and that this file, which is located on your master under Lev<n>/Web/Scripts/AppServer/props, is referenced when you run the commands you mention. In here you will find the names of all the applications you have deployed in the environment and the name of the application server instance that was configured to manage an application. For example on one of my systems in this file I have the following entries: application.15.name=SASThemes9.4 application.15.serverName=SASServer1 ... application.20.name=SASVisualAnalyticsServices6.3 application.20.serverName=SASServer12 These properties tell me that SASThemes9.4 is the "application-name" of the application I want to undeploy and that SASServer1 is the "server". If I wanted to undeploy only this application the command syntax would look like: appsrvconfig.cmd -e run undeploy application SASThemes9.4 server SASServer1  <- This is for Windows. Use appsrvconfig.sh for Unix. If I wanted to undeploy everything that is managed under SASServer1 I could specify "all" for the application-name instead: appsrvconfig.cmd -e run undeploy application all server SASServer1 For SASVisualAnalyticsServices6.3 I would use: appsrvconfig.cmd -e run undeploy application SASVisualAnalyticsServices6.3 server SASServer12 And for everything under SASServer12 I would use: appsrvconfig.cmd -e run undeploy application all server SASServer12 So once you have the syntax down the easiest way to retrieve specific applications names for apps that are defined in your environment would be too look for the application.<xy>.name in the properties file. Then you could use the technique described in the Executing a Batch Script section to capture all these commands in a script so you don't have to run them individually on each horizontal cluster. ... View more

Hi Jlochoa. I've asked one of our SAS Studio experts in SAS Technical Support to try to reproduce your problem and she was not able to recreate it. For her system concatenated libraries defined in metadata are functioning correctly in SAS Studio. Since there is likely some subtle difference between your system and her's I'd like to recommend that you open a track with SAS Technical Support so they can triage the issue with you more directly via a shared session or something similar. If you will send email to support@sas.com and add a subject of "Concatenated libraries and SAS Studio" that will create a track and the resource I've spoken will be looking for it. Please include your phone number in the email so she can give you a followup call. ... View more

Hi Scott. When you hover over the info icon you should see additional information pop up. If that is not happening for some or any of the products that have the info icon by them then that would be bug and we'd want to get a defect opened. Let me know if you find this to be the case and for the specific product and I can then find a resource internally here to check it out and try to reproduce the behavior. ... View more

Sounds like you have a track with Technical Support. That's the best route to go when the answer is not quickly determined. ... View more

Thanks for the clarification. I will check around to see if this is a known issue and will follow up with what I learn. ... View more

Hi GregINGov. You are getting this return code: -1073741515 That is a Windows system return code that indicates that some DLL on your system cannot be access by the account installing the software. Grant t your installation account Full Control on D:\apps\dot\SASHome\ Apply the permissions to all subfolders and files. Then hit Retry on the SAS Deployment Wizard. ... View more

Hi Jlochoa. I assume you mean the second library does not appear rather than the second table. To my knowledge there are no bugs open reporting that concatenated libraries do not work correctly in SAS Studio so I was trying to determine if this might just be a display issue with the Library property dialog or if you could, in fact, not access any tables in the second library. Either one would generate a bug to be created. So my question was: When you are using SAS Studio are you just not seeing the second path in the properties dialog or are you finding that if you place a SAS table (not also found in the first path) in the second path that this table is [also] not known to SAS Studio? I can pass this issue along to our SAS Studio developers and have them investigate it if you would prefer. ... View more

Jlochoa. The reason for specifying multiple paths would be that you want SAS to search more than one path for SAS files when running code using that library reference. It's called library concatenation and it's documented here, SAS(R) 9.4 Language Reference: Concepts, Fourth Edition. The "Rules for Library Concatenation" are certainly worth reviewing, especially: When a SAS file is opened for input or update, the concatenated libraries are searched and the first occurrence of the specified file is used. When a SAS file is opened for output, it is created in the first library that is listed in the concatenation. Whey you are using SAS Studio are you just not seeing the second path in the properties dialog or are you finding that if you place a SAS table (not also found in the first path) in the second path that this table is not known to SAS Studio? ... View more

Hi AnkitDedhia. Usually when you are sharing multiple deployments on the same machine the process would be to create and build out one environment (PROD) and then migrate what you have there into a duplicate environment (TEST) which gives you the flexibility to test updates and modifications without impacting your production jobs and environment. For this reason, the topic of "peaceful coexistence" is handled in the migration guide of SAS documentation, Migration: SAS Intelligence Platform and Business Intelligence. If your host is UNIX or LAX the task is much easier as your biggest concerns will be unique port numbers between the two environments and unique locations for your install binaries and configuration files. On Windows you also have to be concerned with service names being unique and possibly some registry considerations. The Lev4 versus Lev5 selection in the SAS Deployment Wizard will cause most port numbers to change (you will want to verify each one carefully) and since most service names have the "Lev<n>" denoted in them the names should be unique. Still I would recommend a dry run using the -record option (without -deploy) so that you can get a response file and see what each value in the second system will be set to in order to ensure everything is unique between the two environments. ... View more

Hi Maheswara. In addition to setting up symbolic links and defining the version of Oracle installed by running the task in the SAS Deployment Manager as Mark described, you will also want to refer to Chapter 9 of this guide on SAS' support site: http://support.sas.com/documentation/installcenter/en/ikfdtnunxcg/66380/PDF/default/config.pdf. Environment variables in this section are best managed by defining them in the sasenv_local file under <SASHome>/SASFoundation/9.4/bin. The ACCESS team in SAS Technical Support will be able to assist you with any issues you have defining variables. I believe they also can tell you about a utility provided by Oracle that help you ensure things on that end are setup correctly. If that's not done right the Access to Oracle component won't work for you. ... View more