BookmarkSubscribeRSS Feed

Getting ready to install SAS Viya 3.4 on Windows? Then read on.

Started ‎10-05-2018 by
Modified ‎10-05-2018 by
Views 4,654

If you have read my previous article, Installing SAS Viya 3.4 on SUSE Linux...What's the difference?, then you are aware that a SUSE deployment is very similar to the deployment that we knew from the very beginning of SAS Viya on RedHat or Oracle Linux.


Installing SAS Viya on Microsoft Windows is a different story.


Since its initial release (a little more than 2 years ago), SAS Viya was only available on Linux. But from mid-September 2018, SAS Viya is now available on Microsoft Windows platforms. This change has key implications for technical architects and installation engineers involved in SAS Viya deployments on MS Windows. This article highlights the key differences and aims to build some readiness deploying SAS Viya on MS Windows.




If you prefer the short version and want to have an overview of the differences between Linux and Windows deployments of Viya, just jump to the conclusion of this post.


Yes, MS Windows is supported and here are some key considerations


It is possible to perform a "Programming only" or a "Full" deployment on Microsoft Windows Server 2012 R2 (64-bit) or Microsoft Windows Server 2016 (64-bit). At this time, there are several constraints in this initial version compared with the release on Linux:

  • Single machine deployments only:
    • All the Viya components (CAS, Viya supporting services, Infrastructure servers, Programming Runtime) are installed on a single machine.
    • CAS is only supported in SMP mode AND must coexist with all the other Viya components on the same machine.
  • Only supports a subset of Viya solutions:
    • Visual Analytics, Visual Statistics, VDMML
  • Only supports a subset of SAS/ACCESS engines:
    • SAS/ACCESS Interface to ODBC
    • SAS/ACCESS Interface to PC Files
    • SAS/ACCESS Interface to PostgreSQL
  • Only supports Kerberos for the authentication with the visual interfaces in a full deployment

As this deployment is single-machine only, due attention should be paid to the hardware requirements. For more information please read SAS Viya 3.4 Deployment Guide. As with all single host-machine deployments, careful consideration needs to be given to the appropriateness this approach for a given number of concurrent users, size of data, types of workloads and predicted growth in each over time.


It also means that at the September 2018 release, there is no support for higher availability configuration on MS Windows at this time and the only way to scale (staying on Windows), will be to scale up the hardware or the virtual machine capacity.


If HA and MPP are part of the customer requirements, then (as of today) the recommended solution would be to deploy SAS Viya on Linux hosts.


There are other architecture differences between the September 2018 release on Microsoft Windows and the Linux based release of Viya 3.4:

  • Limited resource management capabilities for CAS (Quotas and CPUSHARES, but not MEMORYSIZE or CPU Shares through Priority Levels),
  • Using GPUs to perform deep learning or image processing is not supported on MS Windows based deployments,
  • No support for multi-tenancy,
  • SAS Secret Manager (vault) is not installed as part of the Windows deployment of Viya (although TLS encryption is enabled by default for the communications with the Apache HTTP server and can be enabled for CAS communications).

It's important to note, there are also differences in terms of administration (regarding the services management), but I'll stop here as the focus of this article is the deployment.


System requirements


Just like for Linux deployments, there are many system requirements that need to be implemented by the customer and verified by the SAS Installation team to ensure a smooth and successful deployment.


The system requirements are documented in the official deployment guide, but some of them require additional attention to ensure a smooth installation.

  • Windows Defender Credential Guard

    In Windows server 2016, there is a feature called "Credential guard" which impacts the way SAS products (SAS 9 and Viya) work with IWA. For SAS Viya installations on MS Windows "Credential guard" must be disabled. 




    You can easily check that in the "System Summary" of windows:



    Check the Windows Credential Guard status.




  • PowerShell unrestricted execution

    This requirement is something that the customer system administrator will need to authorize. PowerShell by default runs with a "restricted" policy. However, to be able to install Viya, we need to change that to either "unrestricted" or to another policy (only restricted and undefined are not supported for a Viya deployment).


    The "AllSigned" execution policy can be offered as a trade-off. In this case, it is required to install SAS Signing Certificates in the "TrustedPublisher" certificate store on the Windows machine (SAS Signing certificates are provided as part of the generated deployment scripts).


  • Sufficient free space on the "C:" drive

    By default, the SAS Viya binaries will be installed in "C:\Program Files\SAS" and the Viya configuration will go under "C:\ProgramData" (hidden folder by default). So for example, you'll need to have at least 50 GB of free space on "C:\" if you intend to deploy VDMML.


    And it is just for the beginning (to be able to install and start the services) as logs and operational data will quickly grow to exceed that amount. Therefore, the actual disk space that is required will depend on the amount of data and the level of activity in your specific deployment.


    There are alternative approaches if the host machine does not have enough space on the "C:" drive. They are discussed later in this post.


  • Different requirements depending on the Windows version (2012R2 or 2016)

    When you perform the system requirements checks, make sure you consider your exact OS version, as some requirements are different if you are installing on Windows 2012 R2 or Windows 2016.


  • The CAS account requirements


    We need to have a domain service account for CAS. There are several requirements for this account and care needs to be taken for each.

    • It must be a domain account (for Kerberos Authentication)
    • It must be part of the local Administrators group on the machine where Viya is installed
    • It must have "Log on as a Service" and "Replace Process Level Token" privileges defined in the Local Security Policy.
    • And then if you are doing a “Full” deployment you have the Kerberos requirements associated to this account.


To assist with checking the Kerberos configuration settings, a new tool has been developed to check (and potentially implement) the security/users requirements as well as some elements required to tune Windows for a Viya deployment. It’s called "SAS Viya Deployment Assistant for Windows" and should help you to "Evaluate the Kerberos Configuration and Windows Tuning". The usage of the tool is documented in the official deployment guide.


Pre-installation tasks


As with the Linux version, for a windows deployment:

  • You should use the Mirror manager to build a local repository (with all the required MSI packages) and use it for the deployment
  • You must use the Orchestration CLI to generate the deployment artifact

In a Linux deployment this artifact was a compressed file (SAS_Viya_playbook.tgz) containing all the deployment playbooks (site.yml, deploy-cleanup.yml, etc...), associated configuration files (inventory, vars.yml, etc...) and the license files.


In a Windows deployment it is also a compressed file ( but containing all the deployment wrappers and PowerShell scripts (setup.bat, remove.bat, etc...), associated configuration files (vars.psd1, etc...) – as illustrated below.



Content of the archive




As with its Linux counterpart, the installation itself in Windows is straightforward and "GUI-less." i.e. it is command line driven 😉


You basically open a DOS command, move to the “power-shell-deployment” folder, and type "setup.bat," and wait.


Time should be allocated not just for the installation but also the time taken to download the MSI package.


The setup.bat script will do the following things:

  • Installation phase:
    • Download the MSI packages from the repository and place them in the "Downloads" folder (this can be deleted post-deployment to save space, as it can take up to 20 GB or disk space).
    • Install the MSI packages
  • Configuration phase:
    • Configure all the SAS Viya components and services (CAS, PostgreSQL, consul, RabbitMQ, microservices, etc...)
    • Start the services (as you can see in the screenshot below, the setup script is proceeding carefully with the services startup, monitoring the CPU utilization and, when too high, pausing before starting the next service).


      A careful Services Startup

Note that you can decide to run only the installation (setup.bat -install) as a first step, followed by second step for the configuration (setup.bat -config) phase.


Some important considerations for the installation


This list is not be exhaustive but here is what you should be aware of:

  • The location of the installation directory: In the Linux version, the software binaries and configuration are required to be installed in /opt/sas/viya. In the September 2018 release of Viya 3.4 on Microsoft Windows, the current supported manner is to install into “C:\Program Files\SAS” (binaries) and “C:\ProgramData\SAS”(configuration).

BUT just like in the Linux world you can create a symbolic link with mklink to point “C:\ProgramData\SAS” to your “D:” drive if you want conserve space on your C drive (However be careful with this folder : Microsoft recommend not linking or moving “ProgramData” or you’ll prevent Windows updates applying to the system!).


Additional features to allow future releases of SAS Viya to be installed into a different directory other than “C:\Program Files\SAS” are currently being considered.

  • There is no "installation report" when the script exits

    At the end of the installation, you will (hopefully) see something in your DOS windows like:


    Deployment completed at 09/20/2018 07:29:40
    Install successful.
    Deployment finished with return code '0'
    Transcript stopped, output file is D:\sas\install\powershell-deployment\deploy-20180920T0420052599.log
    Press any key to continue . . .


    That is great as it means you were successful with the installation. However it does not mean that there was no configuration errors...because they don't interrupt the script execution and are not reported at the end.


    So unless you were staring at your computer screen during the 1 to 3 hours of the installation time, you might have missed the error(s). So you might think everything is perfectly well, whereas something actually went wrong during the configuration.


    So the current recommendations are:


  • Use a symbolic link for "C:\ProgramData\SAS", so the configuration and logs can go on a larger disk drive

  • Always check the deployment log file (located in the deployment script folder), to ensure that there was no error during your installation.


  • Idempotency: if it fails can I just re-run my setup.bat?
    • If there is an installation failure during the installation phase.


    Imagine you forgot to install the Visual C++ redistributable libraries and your deployment stops with an error like:



    What happens if you forget a system requirement


    What can you do?


    Well... I have to confess that, as a SAS 9 Installer "veteran", my first natural reflex and idea, for a windows setup, was to use the "Program and feature" assistant to uninstall any previous SAS software installed or look for some uninstall executable, then fix my issue, then restart from the start.


    But, actually you don’t have to do that!


    All you have to do is to fix the error (for example install the missing Microsoft libraries) and just re-run the setup.bat!


    Does it remind you something? Yes, the famous Ansible idempotency that is observed when deploying Viya on Linux based host-machines!


    So, if you run the setup.bat one more time, it won’t download any package that is already downloaded, and it won’t install any MSI that was already installed, it will just skip the step.


  • Now, what if there is an installation failure during the configuration phase?


    In most cases if a configuration step fails, the deployment will continue automatically (One notable exception is if PostgreSQL configuration fails, the deployment will halt). If a configuration step fails, and the cause of the failure has been resolved, run setup.bat -config. This will run the configuration again. Any successfully completed configuration steps will not be harmed.


    There is a good level of "idempotency" in the setup.bat script, which is great as it saves time and effort for the installation engineers. However there are differences between Linux and Microsoft Windows operating systems, so you should exercise caution.


    So, a current recommendation when installing Viya on Windows still applies: before starting the configuration process, ensure that you have a valid system backup, so you can restart from a clean point.


Post-installation tasks


Once the installation is completed successfully, you will need to complete the required Viya post-installation tasks: set the password for "sasboot" and configure the SAS Identities microservice in Environment manager to connect it to the LDAP provider.

However, with a Windows full deployment, as it requires Kerberos Authentication, you also must configure SAS Logon Manager for the Kerberos Authentication.


Conclusion: Deployment differences


To wrap up what is perhaps a longer blog entry than normal,  a table summarizing key differences and similarities between a Linux and a Windows full deployment is presented in the table below:


Deployment steps (full deployment) Viya on Linux Viya on Windows
Pre-requisite: Installation user requirement root or sudo privilege + SSH access from the ansible controller to the target machines. A local Administrator account is required to perform the system checks.


Unless they already exist, a domain administrator has to create CAS and HTTP domain accounts with appropriate configuration for Kerberos.
Prerequisite: System requirements Use VIRK to automate or follow the documented steps for:
  • Supported Ansible version installation
  • Java version
  • libraries and packages
  • SElinux
  • Ports check
  • Linux tuning
Perform manually the check of each requirement:
  • PowerShell version and execution policy
  • Java (version, JCE, SAS_JAVA_HOME environment variable)
  • Visual C++ Runtime components
  • Credential guard
  • User dynamic ports range change
  • Windows tuning (in the registry)
Pre-requisite: User requirements
  • Linux group named “sas”
  • Local or domain CAS account with same UID/GID on all the target machines and member of “sas group”
  • Other groups (apache, postgres) and service accounts (sas, sasrabbitmq) are created during the installation
  • A domain account for CAS, member of local administrator, with specific privileges
  • A local or domain account for postgres with specific privileges
  • End-users who log on to SAS Studio 4.4 must have the Windows privilege to Log on as Batch Job.
Pre-requisite: Security requirements LDAP is required for SAS Viya visual interfaces. It is not required in a programming-only deployment.
  • Read the “Evaluate the Kerberos Configuration and Windows Tuning” section in the Viya 3.4 Deployment guide.
  • Kerberos mandatory for “Full deployments”
  • SPNs must be created for CAS and HTTP and mapped to the corresponding accounts.
  • The both accounts must be trusted for delegation.
  • The machine object must be trusted for delegation in Active Directory.
Pre-installation tasks
  • Build a local repository of RPMs with Mirror Manager (recommended, mandatory with SUSE)
  • Generate the ansible deployment playbook (SAS_Viya_playbook.tgz)
  • Build a local repository of RPMs with Mirror Manager (recommended)
  • Generate the PowerShell deployment scripts (
  • Encrypt CAS and postgres password using the generated PowerShell scripts.
Installation Run an ansible playbook that will download and install RPM packages on the target servers:


ansible-playbook site.yml
Run a DOS batch that will call PowerShell scripts to download and install MSI packages on the local host:


setup.bat [installDir=]
Mandatory Post-installation tasks
  • Reset sasboot password
  • Configure the identity provider (LDAP)
  • Reset sasboot password
  • Configure the identity provider (LDAP)
  • Configure SASLogon for Kerberos Authentication (in Environment Manager)


That’s it for today 🙂
Thanks for reading!


Credits: Many thanks to my GEL and Development Teams colleagues for their help and contribution in the setup and testing of the SAS Viya deployment in Windows.


I am getting below error while installing SAS Viya 3.4 on Linux:

"msg": "Could not find or access '/tmp/tmp.5K8xz3aPNJ/deployTarget/sas/' on the Ansible Controller.\nIf you are using a module and expect the file to exist on the remote, see the remote_src option"


Kindly help.

Hi mpratapwar1 

Sorry for the late answer.

This error message can have various causes.

After double checking the pre-requisites (espeically for the installation account), you could try to undeploy, and try again.

But my recommendation is (unless you did it already) to open a track with the SAS Technical Support.



Version history
Last update:
‎10-05-2018 09:18 AM
Updated by:



Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.

If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website. 

Register now!

Free course: Data Literacy Essentials

Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning  and boost your career prospects.

Get Started

Article Tags