You're right.  Cloning does indeed equate to copying files on a UNIX system.  My earlier responses was related to the suggestion of simply copying a subset of directories ("APPDATA / CONFIG Path") to your new midtier, and then performing some form of reconfiguration to get it working.  I should have been more precise in my response.  Doing those activities alone will leave behind important files (e.g., those in your installation directory - a.k.a. SASHOME).  On the other hand, if you make sure all files related to your SAS environment are replicated in the same locations on an equivalent system in the new data center, including installation and configuration directories as well as any other directories to which you pointed during configuration (e.g., third-party software locations) and modified operating system files (e.g., init.d) you're essentially cloning your environment, and would make your target system a candidate for the Update Host Name option (assuming you've got a new host name). ... View more

1) You're in unsupported territory here.  As you suspect, moving over your metadata/compute tier, but not your mid tier, brings with it metadata supporting your mid tier.  If you then try to install/configure a brand new mid tier as essentially an "add-on" to this environment, there's no guarantee the original mid tier metadata won't get in the way of the new mid tier deployment. 2) Unfortunately, this is also unsupported.  Moving deployments by copying configuration directories from one machine to another is not a valid approach for 9.2, 9.3, or 9.4, unless you're doing full cloning.  As an aside, the equivalent previously mentioned doc for 9.2 is http://support.sas.com/documentation/cdl/en/bisag/64088/HTML/default/viewer.htm#a003361854.htm ... View more

Have you considered simply unconfiguring/uninstalling your mid tier from the source environment, cloning (or migrating via the SAS Migration Utility) your meta/compute tier onto your new environment, and finally doing a fresh mid tier deployment as an add-on to your new environment?  You might find the information at http://support.sas.com/documentation/cdl/en/bisag/67481/HTML/default/viewer.htm#p1gs13ueroyethn11y3tpku021sd.htm useful if you end up going the cloning route. - Mark ... View more

In addition to the thread Jaap cites, you might also want to check out the following white paper: http://support.sas.com/resources/papers/MovingVirtuaVMware.pdf It provides comparisons w.r.t. performance and resource consumption between physical and virtual environments.  Although the paper is written from the perspective of moving from a physical to a virtual environment, you should be able to use the information as you plan to move in the opposite direction. ... View more

If you've got Update 1 installed on top of Windows 8.1, it's likely you're running into the problem described at: http://support.sas.com/kb/52/767.html ... View more

The Windows registry is used for file type associations.  You should be able to have 9.3 and 9.4 versions of SAS deployed and active on the same Windows machine.  As mentioned earlier in the thread, if your deployment involves SAS servers (e.g., Metadata, Workspace, and Stored Process), you need to make sure the two sets of servers are talking on different TCP communication ports.  If you're not aware of using ports, you're probably not using these SAS Servers as the need for ports is included in preinstall checklists associated with "planned" (i.e., Metadata Server-based) deployments.  The port numbers are prompted for during execution of the SDW. ... View more

Yes, side-by-side installations of different versions of SAS are supported on all operating systems. With UNIX and z/OS, there's really no overlap as long as you use different installation locations. For Windows, the most recent one installed is the one which will be associated with file extensions like .sas in the Windows registry.  Only one version can be "registered" in this way at a time [makes sense since you probably wouldn't want to bring up both versions of SAS when double-clicking on a .sas file].  However, even though only one version can be registered for filetype associations, both versions are fully functional. ... View more

The SAS Deployment Wizard's record/playback functionality should be able to help you out here.  You can capture a response file for each of your use cases by running through Deployment Wizard's dialog flow specifying the clients you want deployed.  You can then drive your client deployments silently by specifying the response files in provisioned calls to the Deployment Wizard. Details can be found in the "Record and Playback" section of the SAS Deployment Wizard User's Guide at: http://support.sas.com/documentation/installcenter/en/ikdeploywizug/64204/PDF/default/user.pdf. There's also a relevant white paper (soon to be updated for SCCM) on this approach at: http://support.sas.com/resources/papers/290-2008.pdf - Mark ... View more

If you're using the cost algorithm for load balancing, I believe you could set the maximum cost on machine A to 0, which should effectively eliminate it from consideration in launching workspace servers.  See: http://support.sas.com/documentation/cdl/en/biasag/62612/HTML/default/viewer.htm#n07031intelplatform00srvradm.htm ... View more

You need an object spawner on every machine which hosts a workspace server (or stored process server or pooled workspace server).  That means machines B and C will need one.  You'll use load balancing in order to distribute requests from a parent object spawner to a child object spawner.  There's a description of this in the Application Server Administration Guide at: http://supportprod.unx.sas.com/documentation/cdl/en/biasag/62612/HTML/default/viewer.htm#n07001intelplatform00srvradm.htm ... View more