Ansiple script windows patching

-
Ansible patching activity document
1.    Server-ansible  – Ansible server.
prod1, prod2, sql, Manual
2.      [root@Server-ansible analytics]# cat /etc/ansible/hosts – validate the server list.
3.      Edit the if required to remove or add the servers,

[Manual]

Server1
server2
server3
server4

[sql]

Server5
server6
server7
server8

[prod1]
Server9
Server10
Server11
Server12
Server13
Server14
Server15

[prod2]

Server16
Server17
Server18
Server19
Server20
Server21
Server22
Server23
Server24
Server25


[test]

test server- fgtd-nte1-windows_testvm-app001.mhint – this server only for testing don’t use anyware.

4.      Checking the access for list of servers.
ansible Manual -m win_ping – This cmd to check the ping communication on the remote servers one by one.
Manual is the list of servers already defined
ansible prod1 -m win_ping
ansible prod2 -m win_ping
ansible sql -m win_ping

5.      Reboot and update the non sql servers
[root@Server1 analytics]# 
ansible-playbook prod1-reboot -vvvv | tee prod1_reboot_op.txt  -  For reboot,
ansible-playbook prod1 -vvvv | tee prod1_updateresult_op.txt  - update and result
ansible-playbook prod2-reboot -vvvv | tee prod2_reboot_op.txt- For reboot cmd
ansible-playbook prod1 -vvvv | tee prod2_updateresult_op.txt  - update and result

6.      Update the patch SQL servers.
ansible-playbook sql -vvvv | tee sql_op.txt  - For no reboot only update,

output:-

[root@Server1 analytics]# 

ansible-playbook prod1-reboot -vvvv | tee prod1_reboot_op.txt

ansible-playbook prod2-reboot -vvvv | tee prod2_reboot_op.txt

ansible-playbook sql -vvvv | tee sql_op.txt 
11:50:46 AM
ok: [fgprd-bbdemoapp001] => {
"changed": false,
"found_update_count": 0,
"installed_update_count": 0,
"reboot_required": false,
"updates": {}
}
 
12:06:01 PM
[root@fServer1 analytics]# ansible fgprd-bbdemoapp001 -m win_updates -a 'category_names=CriticalUpdates'
fgprd-bbdemoapp001 | SUCCESS => {
"changed": false,
"found_update_count": 0,
"installed_update_count": 0,
"reboot_required": false,
"updates": {}
}
[root@Server1 analytics]# ansible fgprd-bbdemoapp001 -m win_updates -a 'category_names=SecurityUpdates'
fgprd-bbdemoapp001 | SUCCESS => {
"changed": false,
"found_update_count": 0,
"installed_update_count": 0,
"reboot_required": false,
"updates": {}
}
[root@Server1 analytics]# 
12:12:10 PM
fatal: [Server2]: FAILED! => {
"changed": false,
"error": "Exception calling \"Search\" with \"1\" argument(s): \"The service cannot be started, either because it is disabled or because it has no enabled devices associated with it. (Exception from HRESULT: 0x80070422)\"",
"failed": true,
"location": "at DoWindowsUpdate, <No file>: line 72\r\nat <ScriptBlock>, <No file>: line 222"
}
Using module file /usr/lib/python2.7/site-packages/ansible/modules/windows/win_updates.ps1
 
12:13:01 PM
ok: [Server4] => {
"changed": false,
"found_update_count": 0,
"installed_update_count": 0,
"reboot_required": false,
"updates": {}
}
 
12:19:14 PM
ok: [Server5] => {
"changed": false,
"found_update_count": 0,
"installed_update_count": 0,
"reboot_required": false,
"updates": {}
}
 
12:39:40 PM
fatal: [Server6]: FAILED! => {
"changed": false,
"error": "A reboot is required before more updates can be installed.",
"failed": true,
"location": "at DoWindowsUpdate, <No file>: line 125\r\nat <ScriptBlock>, <No file>: line 222"
}
 
12:54:58 PM


Comments

Post a Comment

Popular posts from this blog

Using Non-Maskable Interrupt (NMI) facilities to troubleshoot unresponsive VMware Virtual Machine.

-
Using Non-Maskable Interrupt (NMI) facilities to troubleshoot unresponsive VMware Virtual Machine. 1, Need to identify the ESXi host name, Where the hung VM running. 2, Login to ESXi server using Putty and run ‘vmdumper –l’ for find world id(wid) of the hung VM 3, Run ‘vmdumper <wid> nmi. 4, After send NMI signal, we can see dump creation in the VM console. 5. Export the System log on particular VM,
Read more

Removing invalid linked clone entries automatically using the ViewDBChk tool

-
Removing invalid linked clone entries automatically using the ViewDBChk tool in VMware Horizon View 5.3 and later versions (2118050) he ViewDbChk tool allows administrators to scan for and fix provisioning errors that can not be addressed using View Administrator C:\Program Files\VMware\VMware View\Server\tools\bin viewdbchk.cmd --scanMachines --desktopName Intertrust_Global_Desktop_x64 --limit 6 --force To run the View DbChk tool: If required, unzip the tool into a new folder. Click  Start  >  Run , type  cmd , and click  OK . The Command Prompt window opens. Navigate to the ViewDbChk tool: For version Horizon View 6.1,  ViewDbChk  is located under:  C:\Program Files\VMware\VMware View\Server\Tools\bin . For Horizon View 5.3 or 6.0, navigate to the folder created during the unzip process in step 1.   Enter  ViewDbChk  with the required flags as listed below into the command prompt to find and clean your database ...
Read more

VMTool update steps on Horizon VDI Parent VM

-
VMTool update steps on Horizon VDI Parent VM The order should be as follows: 1 - Turn on the parent VM  and login 2 - Uninstall VMware Horizon Agent and reboot 3 - Uninstall VMware Tools and reboot 4 - Delete the following registry keys and directories if applicable(dependant on Guest OS), then reboot the VM: HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Tools HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VDM <C:\Program Files\VMware\VMware View\*.*> <C:\Documents and Settings\All Users\Application Data\VMware\VDM\*.*>  <C:\Program Files\VMware\VMware Tools\*.*>  5  - Install VMware Tools, then reboot 6 - Install VMware Horizon Agent and reboot 7 - Log back in and open CMD and type ipconfig /release, then shutdown the VM 8  - Take a snapshot and recompose the pool =================================================================================== https://kb.vmware.com/s/article/2118048 installation order of End User Co...
Read more