Regarding : Installation of SAS Mid Tier in SAS 9.2

[keds]

Hi all,

Environment Details : SAS9.2 with IBM Websphere , Linux

we a have a problem and we don't know how to get around this.

We have 3 tier Installation of Compute / Metadata and Mid Tier. And our Mid tier is corrupt and we have data from the CONFIG folder .But the SASHOME folder which has the deployment manager is corrupt and unfortunately we don't have a Backup. so will not be able to un configure the old metadata id entries related to SAS Mid tier

Have a lot of Question ,so request your advice

1. can we flush out all the mid tier folders( mean remove )  and install and Config SAS mid tier components  from FRESH ?

2. in doing so will it create a duplicate metadata id entries for Mid tier components in metadata server ?  like webreportstudio ( old env metadata id ) and webreportsudio1 ( new environment metadata id )

3. we are not so concerned:  about the duplicate entries so we can live with it . But will it create any problem to endusers ?

4. will there be any metadata configuration needed on the newly created webreportstudio1 or in any of the other metadata object id's ?

5. will there be any syncronozation needed ? between metadata and mid tier , or the deployment wizard takes care

Have anybody faced this kind of scenario . would be very eager to hear from your experience .

Question like : what all problems we could face if we go with approach of installing from fresh the mid tier to the existing metadata ?

                      what all typical metadata configuration we need to do in this scenario ?

Thanks

Keds

[dpage]

The SASHome components can be re-installed (but not reconfigured) without affecting the SASConfig directory assuming you use the existing depot / plan file. Do you know how much was corrupted? If it was just the deployment manager, I would consider installing something simple like management console, which will bring in the Deployment Manager as well for re-installation.

In terms of reconfiguration, it will fail rather than create duplicate entries.

[keds]

thanks dpage . Unfortunately all in SASHOME is Corupt and as of now we cannot retrieve any information from it . Yes we have the same Depot and Plan file.

1) but the old environments metadata id is already present in metadata server, so how to make it work if we do a fresh install ?

2) if it fails then what would be workaround ?

3) Will fresh install of SAS Mid tier componets work correctly for all the applicaiton and contents to user ?

4) after installing SAS Mid tier do we need to make any configuration in metadata to sync it up with existing metadata server instances ?

Thanks

keds

[dpage]

1) the install phase is metadata independent. A single SASHome can be used for multiple configurations, config knows about sashome, sashome doesn't know about config (there is a single entry in the deploymentreg/registry.xml that points to each config lev, so the SDM can find them to maintain them, but that's it) - I'm suggesting you invoke the SDW, when asked if you want to install / configure, ONLY check the install box, leave the configuration box unchecked. Install to where your original SASHome was (rename what was corrupted)

2) I am suggesting avoid any configuration, because it will fail, and there is no real workaround to remove metadata, short of running the unconfiguration, or starting with a blank slate of metadata.

3) No content should be stored in the SASHome, it's just binaries and source files for building web applications, the running material is all out of the configuration directory

4) If all you're doing is re-install SASHome, config shouldn't be affected.

[keds]

Thanks  a lot dpage. so you are suggesting that we do only install,  due to whic SASHOME get populated and since its is getting installed at the same location as previous there would no change  in any of configuration files needed and it would start working as previous.

1) Do you foresee any other sync up activity we need to perform once we are done with install or a single entry done by SDW in the deploymentreg/registry.xml as you said is enough for make the system up and running

Also i have a question from a laymen perspective ,

2) what if we do install and config both for mid tier why shouldn't it overwrite the metadata settings for existing mid tier components ?

3) if it doesnt overwite why dont it create a different named metadata id ( webreportstudio1 e.g )  and sync up everything and start running . that would be an ideal

     case. yes there would be mess in metadata , but atleast my system will be up and running why not ?

Also i had a experience some time back i had messed the install and config of mid tier configuration and when i did a re install without removing the metadata entries it created a duplicate entries for me in metadata and it was a total mess .... i dont correctly recall it as it was long time back.

4) But you are suggesting that no means a duplicate metadata are created ?

Thanks

keds

[dpage]

1) Nope.

2.) Because the system supports configuring more than one mid tier machine, and it's trying to stop you from accidentally overwriting a working WIP configuration on one machine, with an unsupported duplicate on another machine

3.) Because the same identifier that makes it unique, is the identifier applications use to find themselves. You might eventually be able to string together a working system, but it would likely never be able to migrate or upgrade to a future release. Having a tier reconfigured, without being unconfigured previously isn't a scenario to undertake. You can get multiples of certain objects that support it, Workspace servers, Web Report Studio, Object Spawners, etc. What you can't duplicate is a lot of the middle tier, Foundation Services, Web Infrastructure Platform, Shared Services, Information Delivery Portal

4.) Yes, metadata is only created during the configuration phase, if you do only the install phase, no metadata host information, nor credentials are prompted for, so there's no way for metadata to be involved.