I know that Ansible uses winRM to connect to window hosts, which means it does not fully load a windows profile when connecting to a host, but rather can execute bat/powershell commands remotely.
But is there a method where I can logon as a complete Windows profile using Ansible.
My requirement is that every Monday morning I want an automated job (Preferrabley Jenkins -> Ansible) that will logon to my Windows Server machines (around 10 machines). Currently we have a support team that does this every Monday morning (because the machines are rebooted every weekend), and sometimes 1 or 2 machines are missed out, and I would like to automate this because we have Scheduled Tasks that are supposed to run early in the morning, that sometimes misses to run because support forgets to login to a particular machine.
There are 2 connection plugins for Windows in Ansible PSRP and WinRM. Whatever tasks your support team is performing manually can be automated with Ansible Windows Modules or Powershell commands. Though they are executed remotely, actions are performed on the target servers only.
Related
I'm trying to implement Ansible in our company.
I have 2 huge problems that may cause us to leave this product, but before we give up I thought maybe someone could help us.
Some overall information - We installed ansible 2.1 on RHEL 6.5. We tried to use Ansible Tower but we gave up because of the complexity (most of our use is for ad-hoc commands).
The first issue is managing Windows server 2003. When we want to manage windows servers, we need to run the pre-script, but it only works with PowerShell v.3 and above, while Windows server 2003 is not supporting PowerShell v.3 (it's almost impossible to install this version).
In our company (unfortunately) there still dozens of Windows server 2003 machines.
Is there a way to make Ansible being able to manage those servers?
The second issue is the timeout of the WinRM. When we running an ad-hoc command on windows servers, there are machines that Ansible succeed to make a WinRM connection, but its hang out waiting the command to run (for example, even simple "hostname" commands).
We reduced the ansible timeout, but it's still hang out, so we assuming that it succeed making the WinRM connection but hang after.
There ia a way to configure the time out of ALL the process of ansible per machine, or otherwise configure the WinRM to have timeout after the connection succeeded?
Thanks,
Afik
Basically, no- due to major shortcomings of Powershell 2 for things we need to do, and the incredibly low number of Server 2003 installs left out there, we made PS3 the minimum required version.
There's been a little bit of work done by community folks to make a PS2-friendly version of the WinRM connection plugin to at least get basic Ansible connectivity working there (so "raw" will work, and modules can be transferred/run), but pretty much all the existing modules rely on Powershell cmdlets that don't exist in PS2/S2003. So you'd be back to "raw" for everything, which isn't much more useful than Powershell remoting (other than being able to blast commands to multiple machines at a time). If you want to see that, it's at
https://github.com/elum/ansible and
https://github.com/elum/ansible-modules-core
but we're unlikely to accept this into the core product or support it in any way.
I've a Windows Server 2012 R2 based Hyper-V Host, which contains a Windows Server 2012 R2 VM as a VPN using RRAS and another VM running Debian plus the Jenkins (latest version) master server. Using this VPN, a private hosted Windows Server 2012 R2 VM act as Jenkins slave using those VPN connection. For better distinction, call this one node1.
This is bascially working as expected, but there is a problem: Sometimes, when I start a buildjob on node1, it hangs. Only the first 2 steps (Started through user XYZ and Build on slave node1 in workspace C:\jenkins are shown in the log, then nothing happens. On the master, the node1 is shown as online and is connected to the VPN.
Currently I start Jenkins using a windows task. Using this method, the above happens only sometimes. But as I configured the server, I tried to solve this in a cleaner way by registering Jenkins as Windows Service. As Windows Service, I had the same behavior: In the web panel Node1 is shown as online, but when I start a job on it I only come to Build on slave node1 and then it stops.
Normally the next step should be fetching the latest source code from my git repo. I already had the problem but now found out that it has something to do how Jenkins is started. But for me it seems very strange because running the slave as a Windows Service hasn't worked at least one time, and by running it as a Task it works most of the time.
I only found out that the problem also occurs when I start a job directly after node1 boots. When I then cancel the hanging Job and start it again, it seems to work for a while.
There are few options that I can think of them. According to Jenkins Wiki
If the slave is supposed to start desktop applications you have to
allow the service to interact with the desktop
(Action->Properties->Logon->Allow service to interact with desktop).
Another option can be that Windows services don't have the ability to interact with the windows desktop, meaning that some UI tests might no work as you expect. Do any of the steps may need interacting with the desktop (Windows GUI)?
Just for the sports how about to setup a temporary clean windows server to act as node2 (Jenkins slave) and to check if the problem is been reproduced?
There are some questions regarding this topic, but thought I'd ask my about my unique situation...
Background - We are attempting to execute a QTP script via Jenkins. Now, Jenkins is running on a Windows Server, on which we are having some QTP install issues (that topic is for another thread...). As a workaround, I am trying to execute a simple AOM VBScript invoking QTP on a remote client machine (running Windows XP) and execute the test on that machine...
Setup - Just for initial proof-of-concepts, a .VBS file located on a Windows 7 box (the "calling box") has the following command:
Set qtpApp = CreateObject("QuickTest.Application","WinXPMachineName")
Problem - I am getting the following error on the calling box:
ActiveX component can't create object: 'QuickTest.Application'
I have followed the instructions to set up QTP for remote execution on the Windows XP machine. Note that QTP isn't installed on the Window 7 box .
QuickTest Pro must be installed on the local machine (in your case, your Windows 7 computer) even though you'll ultimately launch QTP elsewhere. This is because Set qtApp = CreateObject("QuickTest.Application", "MyServer") summons the local installation of QTP to open. Once the local QTP is open, it should communicate with the remote server and instruct the remote server to begin the test cases.
So, yes, you will need QTP installed on the local machine. (This is not troublesome if you have concurrent aka 'floating' licenses. If you have the seat licenses, that means they are paying for each individual computer that QTP is installed on. If that's the case, I don't know what to recommend.)
An alternate method:
I've been wrestling with remotely-launching QTP test scripts, particularly by launching them through the Windows Task Scheduler (That way, you wouldn't need QTP on the local machine, only on the remote machine). Here are a few questions I've had that hopeful might blaze a trail:
How can I run a QTP test from the command line?
Remotely managing Scheduled Tasks on another computer: Access
Denied
Unable to remotely schedule tasks from the command line
I was using another automation tool than QTP but I faced the same issue.
I was told I had to have the software "QAWP" installed in both machines to be able to run it remotely, but my company was reluctant on buying a second license for just this and wanted another solution 'Cheaper one'. So:
In the test machine have a batch file that executes your tests.
Add a scheduled tasks in windows that calls your batch file.
from any other machine you can start the scheduled tasks using the command:
schtasks /run /s /tn
both launch and remote machines have to be in the same domain and logged in as the same user that you gave access in the DCOM settings
turn off firewall if possible or add qtp to the exceptions
works perfectly for me
Can anyone tell if Set qtApp = CreateObject("QuickTest.Application", "MyServer") works if working with QTP trail version?
I have QTP trail version on two Win7 64bit machine.
When I use the above code to start QTP on my remote machine form vbscript then it works.
But when i try executing it from QTP it fails.
I have the right DCOM settings and all administrative privileges on both machines and my QTP is also running as admin.
So does it only work when I have licence installed?
To add more info to whoever still looking for answer to invoke QTP/UFT in remote machines:
Using VBScript to invoke QTP/UFT tests in remote machine is old school approach. I would suggest you to use Jenkins. It has tons of advantages.
Check here for more details.
Im working with VS2010 and TFS and the Coded UI tests (CUIT).
I created some CUIT and added them to several Test Cases in Microsoft Test Manager 2010.
These tests are executed in our build-deploy-test steps.
This looks as follows (simplified):
Build application
Deploy
2a. Set snapshot of the Virtual Machine to which the application will be deployed to the snapshot in which the application is not installed
2b. Install application
Run tests
Step 3 contains Coded UI tests, but they cannot be executed (will fail), since there is no active remote desktop connection, which they need to be executed.
Now I would like to add a build step 2c. That automatically connects to the Remote Desktop so that the Coded UI Tests kan be executed.
How should I create this step in the Process Template?
I attempted this myself by running a PowerShell script to connect to a machine via Remote Desktop (see here to see how to use the Remote Desktop command-line utility).
This didn't really work for me personally because I was running this script from the build machine - which I could only connect to via Remote Desktop - and so when I close Remote Desktop it would close the session on the build machine and thus I would not be able to obtain a remote desktop connection with my test environment (plus it wasn't ideal to have to launch Remote Desktop from the build machine).
Therefore, the solution I went with instead was to enable auto-logon on the test environment (there are various ways to do this, I can't remember how I did it, but it's easily Googled).
So in my PowerShell script, which launched from our build machine, I used a command to remotely restart the test environment. With auto-logon enabled, the test environment would start back up with an active session, then I could carry on with Visual Studio Coded UI testing. This worked for me without any issues.
The command I used was something like this:
Shutdown.exe /r \\mytestenvironment
Here is some documentation for it.. If you intend on using this command to remotely restart a computer, don't forget to give your machine permissions on the test environment, otherwise this command won't work.
I then launched a command to sleep for a few minutes, to give time for the remote test environment to start back up again (with an active session), then I launched the tests.
Personally, I used a PowerShell script but you could also use a DOS/Batch script if you are more familiar with that.
Also, are you trying to run the automated tests as part of a build process template?
Let me know if you need any further help.
This is a Windows 2003 (or later) machine that gets switched on every morning, but no one logs on until some hours later.
I want to use the time in between to run a backup script c:\script\backup.cmd
How can I start this unattended after the machine has come up?
I tried 2 registry keys, but this resulted in the script being run after a user logs on (which is too late):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices
In the end I used Windows TaskScheduler, who has such an option, but I was wondering if there is another possibility?
Short answer: GPEDIT.MSC (Start, Run, GPEdit.msc)
Windows 2000 and above [1] offer a computer Startup Scripts collection in the policy editor:
Computer Settings -> Windows Settings -> Scripts (Startup/Shutdown)
There's an equivalent logon script area (i.e. after computer startup, when a user logs on) in the User configuration bit.
Longer:
GPEDIT.MSC is the Group Policy editing console, and runs against the local computer's Local Group Policy store when it's used directly, so it's useful for setting local-only parameters. When using Active Directory, a similar interface is used to edit AD Forest-hosted group policy objects (GPOs), so the same settings are available across a bunch of machines.
The computer startup scripts run in the computer context, i.e. as LocalSystem, as you noted, so they often can't access network drives which require a certain user or group membership to work. When domain-member computers access network resources, they generally (with exceptions) authenticate using their MACHINENAME$ account - which lets you set Share/NTFS permissions to allow a computer to access those resources.
A startup script is a quick and easy way of getting a process running when the machine boots.
The computer startup process will be affected by the time it takes to run the program, though, so you might want to ensure you call it with the START command from a batch file, or specifying not to wait for the executable to complete in whatever script language you use. (the key point there is: run the script asynchronously unless it's critical, or doesn't need to be run asynchronously cos it will always take no time at all. Long boots = unhappy users).
Using a Win32 Service is an alternative option - you can use the SRVANY utility from the Resource Kit to "service-ify" pretty much any executable. VS.Net 2002 and later also let you build a managed service directly.
And Task Scheduler gets much more capable as of Vista/2008, able to run scripts at startup, on idle, and/or when Event Logs are generated or certain other conditions are met: it's pretty cool! Scheduled Tasks has the possible advantage of being able to specify the user account under which the task runs, if that's important to you.
Caveat Scriptor:
http://support.microsoft.com/kb/256320
Run Startup Scripts Asynchronously:
http://msdn.microsoft.com/en-us/library/ms811602.aspx
Vista Task Scheduler (what's new):
http://technet.microsoft.com/en-us/appcompat/aa906020.aspx
[1] Windows XP, 2003, Vista/2008, Windows 7/2008R2, Windows 8/2012, Windows 8.1/2012R2, Windows 10/Windows Server 2016. Everything. But NT4 didn't!
You have already outlined a good solution:
Setup a scheduled task to run at Start Up and allow the job to run when the user isn't logged on.
You can run a script at system startup using group policy gpedit.msc
The way you aleady do this seems fine to me; however if you want an alternative approach then services get started when the machine boots so you could write a service that detects if it's a new day (to allow for reboots) and if it is then run your backup.
If I was doing this as a service I'd use TCL because I know it and like it and it has an extension twapi that allows you to run a script as a service. Other scripting languages may well have similar facilities.
There is, if you're using Active Directory. If you can isolate the computer to its own OU or use WMI filtering, you could assign a GPO which has a startup script for the computer. This would ensure that even if someone went in via safe mode and disabled the Task Scheduler, upon startup and connection to the domain, the script would run.