How to deploy Microsoft Office using Ansible?

[Tuyen Nguyen]

Hi

How can we deploy Microsoft Office through Ansible?  Should I use the win_package module?  What options should I use?

[Jordan Borean]

You have 3 options;

• Use win_chocolatey
• Use win_package
• Use win_command

There are some Office packages on the public chocolatey repo https://chocolatey.org/packages/Office365ProPlus but if using this internally you probably want your own package which is a bit more complicated. The win_package and win_command modules will do the same thing for you but win_package gives you more options for idempotency checks but they install it the same way. IIRC for Office you need to setup an install XML file which tells the installer what programs to install and how. Using win_template to template this XML file is a good idea but you would need to go online to Microsoft's docs to see how that can be done.

Thanks

Jordan

[Tuyen Nguyen]

Hi

Thank you.  We want it internal so win_chocolatey is not an option, and I have an XML for an unattended install that was are using for our current user installation process.  I was able to get win_package to work to deploy an Office 2016 installation, but I needed to have the software distribution files local on the client, and it did not work when I reference the installer as being on the network share.  Is it possible to get win_package to install directly from a domain network share?  Else, what can I use to copy files from a domain network share to the client, and then I can use win_package to install locally from the client after I have copied it over.

[Jordan Borean]

You can still use win_chocolatey, you would just need to setup an internal repository but that's a bit of extra work so I won't go into it too much. As to why you can't install from a network share, this is a common problem with network authentication that WinRM uses. It does not have access to your credentials to authenticate with a further server so it will be rejected when trying to access network resources like file shares. There are a few ways in Ansible that you can bypass this restriction;

• Use Kerberos with credential delegation, e.g. 'ansible_winrm_transport: kerberos' and 'ansible_winrm_kerberos_delegation: True`
• Use CredSSP, 'ansible_winrm_transport: credssp'
• Use become on the task
• Other options but not really useful or recommended
  

The first 2 options relate to the authentication that occurs between Ansible and the Windows host. Kerberos is highly recommended from a domain environment and having delegation enabled allows you to delegate those credentials to further hosts. CredSSP is similar but is based on unconstrained delegation whereas Kerberos can be constrained if configured.

Using become is probably the easiest option and we have a guide on it here https://docs.ansible.com/ansible/latest/user_guide/become.html#become-and-windows. In your case there are two options

- name: install Package as particular user
  win_package:
    ...
  become: yes
  become_method: runas
  # these should be set in your inventory but is here to demonstrate it
  vars:
    ansible_become_user: username
    ansible_become_pass: password

- name: install Package as current user but with explicit network credentials
  win_package:
    ...
  become: yes
  become_method: runas
  become_flags: logon_type=new_credentials logon_flags=netcredentials_only
  vars:
    ansible_become_user: username
    ansible_become_pass: password

The first example will actually run that process as the specified become user so it would need permission to log onto that host. The second example will run the installer using the connection user, but the become credentials supplied will be used for any network authentication. The benefit of this is that the user does not need to log on locally.

Thanks

Jordan

[Tuyen Nguyen]

Hi

Thank you, I will try it out.  For Ansible to connect to my Windows client, I currently am setting it with the group_vars/windows.yml containing the following:

ansible_user: tu...@DOMAIN.COM
ansible_port: 5986
ansible_connection: winrm
ansible_winrm_transport: kerberos
# The following is necessary for Python 2.7.9+ when using default WinRM self-signed certificates:
ansible_winrm_server_cert_validation: ignore

And I run ansible-playbook with the --ask-pass option so that it would ask for the password.

I have only started using Ansible so I don't really understand the options used, and I found the above options somewhere and they have worked for me.  

With the above setting, I am using Kerberos right?  And so with what you suggested, I should add the become options in the win_package moduleto my playlist.  If I want to use become to use the account I am using to log on already, do I need to set the ansible_become_pass as well, or even the anisible_become_user option as well.  I would like to keep the password outside of the configuration files, and that is why I used the --ask-pass so that it would ask me for the password.

Regards,

Tuyen Nguyen

[Jordan Borean]

I have only started using Ansible so I don't really understand the options used, and I found the above options somewhere and they have worked for me.

Here's a brief explanation of what each var does:

• ansible_user: The username you use to connect to the host
• ansible_port: I'm pretty sure you can omit this as 5986 is the default for WinRM but this says to connect to WinRM over port 5986 used by the https listener
• ansible_connection: Tells Ansible what connection plugin to use, by default it will use SSH but for WIndows we need winrm
• ansible_winrm_transport: Explicitly tells Ansible what auth to use, if you want Kerberos then you're fine here
• ansible_winrm_server_cert_validation: When using HTTPS the listener may be backed by a self signed cert, this tells Ansible to not validate the certificate. If you have an enterprise AD CS environment that creates your listeners, you can use ansible_winrm_ca_trust_path to specify the path of a ca chain to use for the certificate validation

A list of variables you can use in the winrm plugins can be found at https://docs.ansible.com/ansible/latest/plugins/connection/winrm.html. This isn't a definitive list as there are extra vars based on the version of pywinrm installed.

With the above setting, I am using Kerberos right?  And so with what you suggested, I should add the become options in the win_package moduleto my playlist.

Yes, by setting ansible_winrm_transport to kerberos then it will use Kerberos for authentication. Using become is an option but you have another one available to you.

If I want to use become to use the account I am using to log on already, do I need to set the ansible_become_pass as well, or even the anisible_become_user option as well.  I would like to keep the password outside of the configuration files, and that is why I used the --ask-pass so that it would ask me for the password.

Unfortunately yes, become works around the double hop/credential delegation by explicitly logging on the become user specified with the passwords. This requires the credentials to be known at the logon and is completely independent on the connection authentication protocol. Luckily for you Kerberos has the ability to setup delegation without setting a password and is probably the most secure way to setup credential delegation as no password is sent over the wire. To do this, add the variable 'ansible_winrm_kerberos_delegation: True' to your vars and it should mean the WinRM process can use the same kerberos ticket to authenticate with further servers. This is dependent on how AD has set up constrained delegation for the host but by default it should work for you.

Thanks

Jordan