Im trying to automate an MSI installer using Ansible. The MSI performs a lot of the steps but then calls DbTool.exe which opens another CMD window and does a bunch of DB stuff, once complete its closes and the MSI resumes.
When I manually run the below from CMD, its successful:
msiexec.exe /i "Package.msi" /quiet /L*V "PackageInstall.log" ISQLSERVER=(local) ISQLAUTH=sql ISQLUID=sa ISQLPWD=********
However, when I do the same from Ansible the play hangs when the MSI executes Dbtool.exe. I can see it Running in Task Manager but isnt doing anything. When the DBtool executes theres no interaction needed unless theres exceptions when running. The Dbtool.exe creates logs but unfortutantley theres no logs as I dont think its getting far enough to start.
- name: Installing Package
win_package:
path: "{{ Generic_Temp_Path }}\\Package\\{{PackageLatestVersion.stdout}}\\Package64_CTI.msi"
arguments: /L*V "{{ Generic_Temp_Path }}\Package\{{PackageLatestVersion.stdout}}\PackageInstall.log" ISQLSERVER={{ UT_DB_Servername }} ISQLAUTH={{ UT_DB_SA_Auth }} ISQLUID={{ UT_DB_SA_User }} ISQLPWD={{ UT_DB_SA_Pass }}"
wait_for_children: yes
Here is the MSI Log, not a lot to see other than its ran it and waiting:
MSI (s) (5C:04) [09:27:36:132]: Executing op: ActionStart(Name=Database.NUI_CreateDB,Description=Creating database...,)
MSI (s) (5C:04) [09:27:36:132]: Executing op: CustomActionSchedule(Action=Database.NUI_CreateDB,ActionType=9298,Source=C:\Program Files\Package\Utilities\DbTool\DbTool.exe,Target=**********,)
The play is running under AdminUser and is the same account I use to manually run the silent installer from CMD so I dont believe its account related.
Ive asked my dev to add some debugging to the dbtool.exe to maybe see if its hanging at some point but from the current logging, theres nothing to go from.
Has anyone come across this before and know any steps to move forward with debugging?
Many Thanks,
Brad.
Related
I have a powershell script for installing MS SQL 2014 to a Windows Server 2016 (manually tested and confirmed working properly).
powershell script abbreviated:
$sqlInstanceName = {{ sqlInstance }}
$localAdminPword = {{ localAdminPword }}
### Some more variables here declared the same as above
echo [OPTIONS] > $SQLServerInstallerPath\SQLServerConfigurationFile
### more echo lines like the above.
& $SQLServerInstallerPath\setup /SAPWD=$localAdminPword /ConfigurationFile=$SQLServerInstallerPath\SQLServerConfigurationFile
My playbook is simple just hosts for the target host and two tasks, I just generate the script using win_template, and then execute it with win_shell. something like:
---
- name: Install SQL
hosts: "{{ newhost }}"
tasks:
- name: generate script
win_template:
src: "scriptName"
dest: "{{ path }}//scriptName.ps1"
- name: run script
win_shell: ./scriptName.ps1
args:
chdir: "{{ path }}"
Here's a rundown of the scenarios:
Scenario 1:
I use Ansible tower to run the job targeting a server newly provisioned with vRealize Automation.
Output says it's successful, no problems.
I login to the new server and see that MS SQL wasn't installed, the powershell script didn't work... weird,
so I logged off the server and I ran the same job again, no changes, just rerun it.
I logged in the server again, this time, MS SQL was installed properly.
Scenario 2:
I repeated scenario 1 completely, everything the same, this time, I ran the job twice in succession.
I logged in the server, saw the MS SQL wasn't installed.
Logged off, then ran the job again, Logged in, saw MS SQL installed
Scenario 3:
I provision a new server, exactly the same as the previous scenarios, but this time, I logged into it to just look at the desktop, take a peek at the start menu, then logged off.
I now run the same job again once, on this new server I provisioned.
After the job completed successfully, I logged into the server and MS SQL was properly installed.
It seems that it won't work, unless I do a first Login on to the new server before running this job. Which defeats the purpose of automating it... Does anyone have an idea about this? Is there some sort of setting or flag I should look into? (note: the server doesn't have the "change password on first login" thing, as far as I'm aware, I didn't specify any first login things on that server.) I need this to work without doing a first login.
I need to bring up the following service and configure recovery options as below using ansible,
rem Register windows services
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\installutil.exe" "C:\myservice.exe"
rem Configure windows services recovery options
%SystemRoot%\System32\sc.exe failure myservice reset= 600 actions= restart/300000
%SystemRoot%\System32\sc.exe failureflag myservice 1
I can use win_service module to install service.
- name: Install Windows service
win_service:
name: myservice
path: 'C:\myservice.exe'
How do I set recovery options in ansible ? I don't see any free-form text in below given link,
https://docs.ansible.com/ansible/2.3/win_service_module.html
The link you have shared points out to the win_service module in ansible version 2.3 which is quite old.
Meanwhile, I just checked and there is nothing about recovery options either in the latest version of win_service (2.8 at time of writing)
However, there seems to be an ongoing pretty advanced PR that would introduce changes meeting your requirements. There are still some issues to fix and it missed 2.9 code freeze. But hopefully it could come out for the next version.
If you really can't wait you can try to install ansible from the above PR branch. But if you want to keep it safe, you will have to launch commands through the win_command module after installing the service until this PR is released.
I am trying to install the Datadog agent on Windows using PowerShell only, not manual however, the APIKEY is not being setup. Is there a way to update/set the APIKEY after installation?
First you may need to download the MSI file:
$image_url = "https://s3.amazonaws.com/ddagent-windows-stable/ddagent-cli-latest.msi"
$destin = "C:\path\to\downloaded\ddagent-cli-latest.msi"
(New-Object System.Net.WebClient).DownloadFile($image_url, $destin)
The actual powershell command for installation (with extra optional arguments included as arguments):
msiexec /i C:\path\to\downloaded\ddagent-cli-latest.msi /l*v C:\path\to\installation_log.txt /quiet APIKEY="$DD_API_KEY" HOSTNAME="$HOSTNAME" TAGS=`"$TAGS,COMMA,DELIMITED`
It's been a while since i've done this (8 months or so?), so it could be outdated, but it used to work :).
Note, if you're running this from a remote provisioning script, you'll probly have to schedule this to be executed not-remotely so that the installation command can be run with heightened permissions, which i believe is required. And you may need to make sure the computer is plugged into the power source (i remember hitting some infuriating issue where that was an arbitrary requirement for Windows scheduled tasks to run, and Windows didn't allow me to configure around that).
I have a setup.exe file to install on Windows Server 2012. Upon clicking the SETUP file, a PowerShell console will popup and will start the installation process. As the process goes through, I will be asked many questions for initial configuration, such as:
>username:
>password:
...................#starts with setup again with verbose outputs
>SQL Server Address:
>SQL Server Database Name:
..................#starts with setup again with verbose outputs
>Database Username:
>Database user password:
.................#starts with setup again with verbose outputs
>Application Name:
.................#starts with setup again with verbose outputs
..............................................................
I install this application from time to time and I want to know if I can write a PowerShell script to give the answers via the script, since I am a newcomer to Powershell, I am here to seek help.
Thanks
I had no problems with SCCM 2007 scripting application deployments, but SCCM 2012 has me pulling my hair out and I have very little left.
We tend to have heavily scripted installs and most of the time the installs fail in SCCM 2012, the latest failure is symantec enterprise vault, I wrote a script that would check the main DLL plugin version and use the correct uninstall string to remove the previous version, before installing the latest version.
my script is very simple and works fine outside of SCCM, but inside SCCM it fails.
If I recreate the application as a MSI deployment and use the MSI file then it installs fine, so SCCM is working correctly to the client. The uninstall that SCCM puts in from the MSI failed, but that is covered below in the example. I have checked all the client side log files and can not find any issue.
I even return the successfull install return code 1707 and 0 at the end of the script to try and get SCCM to make it a success.
I have written the script first in VB.net as a console service app and then rewrote it in vb script. both scripts fail. I used to use AutoIT to write scripts in the past, but that too was failing, so I thought I would switch to something more microsoft.
For detection I use the windows installer selection and point to the msi file where it picks up the product code.
deployment type is script.
The only thing I can think of is SCCM 2012 does not like the sleeps that are in the scripts.
or it just does not like scripts. :-(
The MSI uninstall failed, because it needed to run as administrator, as you can see from the script below, I run as administrator and this works outside SCCM, but not in SCCM. the install uses pretty much the same code but more logic and many more uninstall strings.
even the uninstall fails and here is how simple the uninstall script is;
Set WshShell = WScript.CreateObject("WScript.Shell")
If WScript.Arguments.length = 0 Then
Set ObjShell = CreateObject("Shell.Application")
ObjShell.ShellExecute "wscript.exe", """" &
WScript.ScriptFullName & """" & "RunAsAdministrator", , "runas", 1
Else
end if
Set objShell = CreateObject("WScript.Shell")
Set objExec = objShell.Exec("MsiExec.exe /x{ADEBB592-4986-4FD1-868C-D59DB32F0BC2} /q")
WScript.Sleep 8000
returnValue = 1707
WScript.Quit(returnValue)
Just because it works outside of SCCM, does not mean a lot if you have to make it work with SCCM! people make that comparison all the time a work and it means nothing, what you need to do, is enable verbose logging on the MSI, the command line it's something like this msiexec /x {xyz-code} /l*v c:\somelogpath.log, try it you may find something equally bizarre like a 1303 error inside the log files
Use PSEXEC and execute the command under system account.
I found some setups/installers do not like to be executed without GUI or other non-user account.
Another thing, in SCCM 2012 you have packages that just simple execute the program, with only exit code check.
And there are Applications that can have detection rules, which can be used to really verify if the program installed/executed correctly.
Also always check ITninja for tips.
Something like this you may need to make sure that outlook.exe is closed you may want to add a taskkill to your script and then try it:
taskkill /IM outlook.exe /T
msiexec /a "path to file" /qn
might work as a simple .cmd file
This is an old thread, but maybe this is helpful for people searching the web:
SCCM Applications usually run as SYSTEM, no need to "run as administrator" (you could configure that within the Deployment Type).
You cannot "break" out of SYSTEM context and do a "run as"
runas and system account.
Tried that once and finally did an ugly workaround by creating a scheduled task that runs under a specific user, then ran that task from my script, which is running as SYSTEM.
As already mentioned, test your scripts interactively using SYSTEM account:
psexec.exe \\localhost -s cmd
Check with whoami that you're running the cmd with SYSTEM.
Make sure you add the COMPUTER account of your test client to the share/folder ACL of your networked scripts folder, otherwise the system account does NOT have access rights.
If running the script as SYSTEM works but SCCM still reports an error, chances are high that the Detection Method failed, NOT the actual install!
Check the following logs here: C:\Windows\CCM\Logs
(See 4. below how to use the index service to speed up troubleshooting logs.)
AppDiscovery.log
AppEnforce.log
AppIntentEval.log
Open up the Windows Indexing Service Options. Configure *.log to index file contents as well. Then add the path C:\Windows\CCM\Logs to the index. Howto.
This way you could easily search for the application name and you will find all log files which deal with that application. You will also find the matching AppDT ID, so you could search for that ID and will find even more info about your package/application.
On your admin machine create a new log collection folder, add this folder to the index. This allows you to copy the whole log folder of a client to your admin folder. A few minutes later it's indexed and fully searchable on your local machine!
There's a tool available from Microsoft which could gather a full log package on a client: ConfigMgr Support Center
Do you have SCCM setup to run it as administrator in the program that you defined?