Exactly how is the "root" of SL determined for a client. I ran across confusing behavior today setting up a test environment for my users.
Despite having a stand alone server with a full installation and its own database, my desktop client connects to the test database just fine, but seems to execute programs from the production environment. I can not figure out how to get my desktop client to point to the test installation of SL (i.e. run the EXE's from my test host - not the EXE's from the production host).
I think I have narrowed things down to the client.cfg in the root of the installation, which has many references to <SOLROOT> in paths. This doesn't seem to be an environment variable, so I assume it is determined at runtime somehow. I do not have this problem if I remote into the test host and execute DL directly there, so this is just a client problem.
Does anyone have advice on how to enable my desktop client to execute code/db on different installations (i.e. both code and database)?
Please find below the steps to define a workstation
1) Take the Solomon installed path from the server (Ex: D:\Program Files\Microsoft Dynamics\SL\Application)
Note: 1) The above mentioned path denotes Solomon root folder
2) The above mentioned path for Dynamics SL 7.0 and SL 2011. If it is SL 6.0 / 6.5 the installed path will be D:\Program Files\Solomon.
2) Share the Application folder with read and write access to Everyone (Because during batch release system will create the event log file under Applications\Eventlog folder. So user needs the write permission too)
3) In the Client machine you have to map the network drive for the above shred path.
4) Install the client using the Setup file under the Mapped Drive\WRKSTN folder
5) After that user can access Dynamics SL in client machine easily
Hope this helps
Well, I already have a client installed ... for our PRODUCTION environment. I wanted to be able to access a completely different installation ... for our TEST environment. That is to say, from my PC I wanted a Solomon client that can to two different installations/environments.
This is why I asked about <SOLROOT> ...
I will try the install approach in a couple days and see what happens, but it was my initial instinct that it would trash or overwrite my existing installation and not achieve what I was trying to accomplish.
The requested way is not advisable since it will overwrite your existing installation as you said.
Thanks & Regards
I guess I am back to figuring out how to change <SOLROOT> then. :-)
Unless I misunderstand your question, you can select which set of .exe's run by starting the SL client with the MSDynamicssl.exe in the location you want to work from.
For instance, when I start SL on my development box, I am running it from D:\Dynamics\SL\Applications - D: being on the local development machine. When I run it for production, I start it from, S:\, which is mapped to the production SL share.
Another method would be to run the development environment using a Remote Desktop Connection. That would ensure that nothing contaminates your local client installation.
While I didn't post it originally, and I did retry it, mapping to different EXE's was my first instinct and attempt.
Given that we have a 100+ screen custom app written in SL, I should be able to execute this app in PRODUCTION, but it should not find the EXE's in TEST because they are not there (yet). I created the new short cut by mapping a drive letter to the root of the TEST installation. Each short cut points to a different drive letter and a different SL installation.
It appears, using this as a test, that the app runs PRODUCTION under both clients (i.e. the custom app executes under both clients).
I am assuming that when I originally installed the SL client on my workstation, the <SOLROOT> was set somehow as a part of the installation process. I do not see it defined in the solomon.ini file, so I am not sure where else to look.
While a Remote Desktop was not what we were trying to do, either this or a virtual machine appear to be the only options.
What I wanted to do was give our users the ability to log into either PRODUCTION or TEST from their workstations to support a testing (our SL genius retired last week and I am taking over - I can't do testing for our users to the degree he could).
Based on what I see in the thread, the options are:
It doesn't appear there are any better options, so we will likely go with one of these. I appreciate the feedback from everyone.
Other Microsoft Sites
I'm a Customer
I'm a Partner
Follow Microsoft Dynamics