ansible-collections / community.windows

Windows community collection for Ansible
https://galaxy.ansible.com/community/windows
GNU General Public License v3.0
204 stars 159 forks source link

win_scheduled_task: RegisterTaskDefinition error using a trigger with start_boundary #53

Open Akasurde opened 4 years ago

Akasurde commented 4 years ago

From @aventrax on Mar 13, 2020 10:38

SUMMARY

When configuring a scheduled task using the win_scheduled_task module I got an error in case the trigger is set daily with a start_boundary using the format specified on the docs. This tasks is part of one of my old roles and it was working with Ansible 2.8.5 but not with 2.9.6.

ISSUE TYPE
COMPONENT NAME
ANSIBLE VERSION
OS / ENVIRONMENT

Ubuntu 18.04 LTS with ansible in a virtual env

STEPS TO REPRODUCE

ansible-playbook -vvvv mio.yml -l 172.16.8.176

--- 
- hosts: all 
  gather_facts: false

  tasks:

  - name: Configuring scheduled task to clean IIS tmp folder daily 
    win_scheduled_task:
      name: IISTmpCleaner
      description: Rimuove file temporanei piu' vecchi di 3 giorni
      actions:
      - path: C:\Windows\System32\forfiles.exe
        arguments: '/P C:\Windows\SysWOW64\inetsrv\tmp /S /D -3  /C "cmd /c if @isdir==FALSE del @file"'
      triggers:
      - type: daily
        start_boundary: '2017-10-09T01:39:00'
      username: SYSTEM
      run_level: highest
      state: present
      enabled: true

...
EXPECTED RESULTS

No errors at all, as of ansible 2.8.5

ACTUAL RESULTS
TASK [Configuring scheduled task to clean IIS tmp folder daily] ****************************************************************************************************************************************************************************task path: /home/matteo/Ansible/MEDarchiver/mio.yml:7
Using module file /opt/python-virtual-envs/default/lib/python3.6/site-packages/ansible/modules/windows/win_scheduled_task.ps1 
Pipelining is enabled.
<172.16.8.176> ESTABLISH WINRM CONNECTION FOR USER: auxonet\medadmin on PORT 5985 TO 172.16.8.176
EXEC (via pipeline wrapper) 
fatal: [172.16.8.176]: FAILED! => { 
    "changed": false,
    "msg": "failed to modify scheduled task: Exception calling \"RegisterTaskDefinition\" with \"6\" argument(s): \"(4,33):Date:2017-10-09T01.39.00\""
}

Copied from original issue: ansible/ansible#68210

ShachafGoldstein commented 4 years ago

can you please post verbose output? -vvvv

Akasurde commented 4 years ago

@aventrax can you please post verbose output? -vvvv

aventrax commented 4 years ago
$ ansible-playbook -vvvv -i inventories/production mio.yml -l 172.16.8.176 
ansible-playbook 2.9.6 
  config file = /home/userx/.ansible.cfg
  configured module search path = ['/home/userx/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /opt/python-virtual-envs/default/lib/python3.6/site-packages/ansible
  executable location = /opt/python-virtual-envs/default/bin/ansible-playbook
  python version = 3.6.9 (default, Nov  7 2019, 10:44:02) [GCC 8.3.0]
Using /home/userx/.ansible.cfg as config file
setting up inventory plugins
host_list declined parsing /home/userx/ansible/inventories/production/hosts.yaml as it did not pass its verify_file() method 
script declined parsing /home/userx/ansible/inventories/production/hosts.yaml as it did not pass its verify_file() method
Parsed /home/userx/ansible/inventories/production/hosts.yaml inventory source with yaml plugin 
Loading callback plugin default of type stdout, v2.0 from /opt/python-virtual-envs/default/lib/python3.6/site-packages/ansible/plugins/callback/default.py 

PLAYBOOK: mio.yml **************************************************************************************************************************************************************************************************************************
Positional arguments: mio.yml
verbosity: 4
connection: smart
timeout: 10
become_method: sudo
inventory: ('/home/userx/ansible/inventories/production',)
subset: 172.16.8.176
forks: 5
1 plays in mio.yml

PLAY [all] *********************************************************************************************************************************************************************************************************************************
META: ran handlers

TASK [Configuring scheduled task to clean IIS tmp folder daily] ****************************************************************************************************************************************************************************
task path: /home/userx/ansible/mio.yml:7
Trying secret FileVaultSecret(filename='/home/userx/.vault_pass.txt') for vault_id=default
Trying secret FileVaultSecret(filename='/home/userx/.vault_pass.txt') for vault_id=default
Trying secret FileVaultSecret(filename='/home/userx/.vault_pass.txt') for vault_id=default
Using module file /opt/python-virtual-envs/default/lib/python3.6/site-packages/ansible/modules/windows/win_scheduled_task.ps1
Pipelining is enabled.
<172.16.8.176> ESTABLISH WINRM CONNECTION FOR USER: auxonet\medadmin on PORT 5985 TO 172.16.8.176
EXEC (via pipeline wrapper)
fatal: [172.16.8.176]: FAILED! => {
    "changed": false,
    "msg": "failed to modify scheduled task: Exception calling \"RegisterTaskDefinition\" with \"6\" argument(s): \"(4,33):Date:2017-10-09T01.39.00\""
}

PLAY RECAP *********************************************************************************************************************************************************************************************************************************
172.16.8.176               : ok=0    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0
ShachafGoldstein commented 4 years ago

Can you please try using a date and time that aren't in the past?

aventrax commented 4 years ago

Tried. No difference.

Anyway, I tried this on a different inventory/host, both are Windows 2012R2 servers but on the new host I had no issues running the same playbook con Ansible 2.9.7. Same OS, same psversion, same locale... The only difference that I noticed is the ansible connection method (ntlm vs kerberos), kerberos on the working server, but I this this is not important at all.

Just to be clear and repeat. Ansible 2.8.5 has no issues on both servers.