We used to savor the joy that is a self updating Eclipse RCP application on Windows XP (it´s an company only internal document management system). Now after switching to Windows7 updates will only be performed if the application is run as an Administrator which of course erases the joy out of the thing that is a self updating application.
The self provisioning is more or less copy/paste from this article
Since the installation folder is bound to C:\Program Files (company policies...) the application may no longer write to this folder, unless started as an elevated process. What p2 does (at least I think after an epic debugging session) is to download artifact.xml and content.xml from the p2 repository to compare locally and build an update plan. Unfortunately if it is not able to store the downloaded files it simply says "Nothing to update".
I already tried to give the shared installation/bundlepool a try, in which the bundles are installed to the user directory using the p2 director application with the following properties:
-metadataRepository http://someserver/updatesite
-artifactRepository http://someserver/updatesite
-installIUs my.application.id
-roaming
-destination "C:\Program Files\MyApplication"
-bundlepool C:\Users\me\MyApplication
-profile DefaultProfile
-profileProperties org.eclipse.update.install.features=true
-p2.os win32
-p2.ws win32
-p2.arch x86_64
-Declipse.p2.data.area=C:\Users\me\.p2
The installer works kind of well and the application may start (after telling her, that the launcher is in my user directory). But unfortunately the self provisiong still doesn´t work this way. Run as administrator will result in downloaded updated bundles and features in the -destination location instead of the -bundlepool location - which is what I expected.
What switch did I miss?
We've had a similar problem here. One of the reasons may be that the IUs being installed still try to write something in the "C:\Program Files\MyApplication" via the p2.inf touchpoint instructions. The solution was to deploy a minimalistic launcher "C:\Program Files\MyApplicationLauncher" which:
performs bundle pool updates (dir = "C:\ProgramData\MyBundlePool")
and actually installs and launches the application in the %tmp% (dir = "C:\Users\username\AppData\Local\Temp\MyApplication")
Related
When building a Service Fabric project in Visual Studio (*.sfproj), a Deploy-FabricApplication.ps1 script is created as part of the template to deploy this application to Azure (or Service Fabric running wherever, for that matter). I'm looking for a way to containerize that mechanism as part of a Windows Docker image since our build and deployment process is containerized. Is there a way to run this script from within a Windows Docker container, and if so, what prerequisites would the image need to have?
Update:
Service Fabric SDK 3.3.617 released as part of Service Fabric 6.4 can now be installed in containers to build and deploy Service Fabric projects. This can be done in a Dockerfile using the following:
ADD https://download.microsoft.com/download/D/D/D/DDD408E4-6802-47FB-B0A1-ECF657BEB35F/MicrosoftServiceFabric.6.4.617.9590.exe C:\TEMP\MicrosoftServiceFabricRuntime.exe
ADD https://download.microsoft.com/download/D/D/D/DDD408E4-6802-47FB-B0A1-ECF657BEB35F/MicrosoftServiceFabricSDK.3.3.617.msi C:\TEMP\MicrosoftServiceFabricSDK.msi
RUN C:\TEMP\MicrosoftServiceFabricRuntime.exe /accepteula /sdkcontainerclient /quiet
RUN msiexec.exe /i "C:\TEMP\MicrosoftServiceFabricSDK.msi" /qn
Here is an example Dockerfile
Original Answer:
Turns out, this is no small feat. This script requires the Windows Service Fabric SDK to be installed. The recommended (and only supported) way to install the Service Fabric SDK is through WebPI, which is available here. It's possible to Dockerize the WebPI, however there's a problem. The WebPI installer consists of three components; the Service Fabric SDK, the Service Fabric Runtime, and the Service Fabric Tools for Visual Studio. The WebPI installer will install all of them. Unfortunately, the Service Fabric Runtime (as of this writing) cannot run under a Docker container since it wants to install a kernel level driver. This bug is being tracked here, but has been open for nearly a year with no real progress. This means that one could not run a Service Fabric cluster within a Docker container, but surely the SDK and tools should still be able to run, correct? Unfortunately, there is no way to tell the installer to only install the SDK and tools, but not the runtime.
So, perhaps there is an unsupported way to install just the SDK and tools. Turns out, the release notes have references to various MSIs for the individual components.
SDK Available Here
Tools for Visual Studio Available Here
It's fairly trivial to run msiexec.exe from a Dockerfile, which means we should be able to install the SDK that way. Nope. Unforunately, msiexec will fail with a generic 1603 code. If you run msiexec in verbose mode and output a log file, you can dig into this error and see the root cause:
MSI (s) (78:34) [19:07:56:049]: Product: Microsoft Azure Service
Fabric SDK -- This product requires Service Fabric Runtime to be
installed.
This product requires Service Fabric Runtime to be installed. Action
ended 19:07:56: LaunchConditions. Return value 3.
So, we're once again shot down. I've found no other packaged version of the Service Fabric SDK (Chocolatey has one, but it just launches the WebPI installer) which leaves one final solution; we install the SDK manually without the help of an installer. This requires reverse engineering exactly what the installer does, and integrating this into our Dockerfile.
The SDK installer does a few things. It copies a bunch of files into c:\program files\microsoft sdks\service fabric\ and a bunch of files into c:\program files\microsoft service fabric\. It also GAC's a bunch of stuff (Such as System.Fabric.dll), adds some stuff to the registry, and also installs a Powershell module. We need to do all those things for the script to run.
What I ended up doing is mounting the key folders as Docker volumes so I can use them within my container:
docker run `
-v 'c:\program files\microsoft sdks\service fabric\tools\psmodule\servicefabricsdk:C:\ServiceFabricModules' `
-v 'c:\program files\microsoft service fabric\bin\fabric\fabric.code:C:\ServiceFabricCode' `
-v 'c:\program files\microsoft service fabric\bin\servicefabric:C:\ServiceFabricBin' `
-e ModuleFolderPath=C:\ServiceFabricModules `
-it build-agent powershell
First, I need to share out the c:\program files\microsoft sdks\service fabric\tools\psmodule\servicefabricsdk directory which contains the Powershell module that the Deploy-FabricApplication.ps1 script loads:
Import-Module "$ModuleFolderPath\ServiceFabricSDK.psm1"
Next, we need to share out c:\program files\microsoft service fabric\bin\fabric\fabric.code because it has a bunch of DLLs that the installer GACs.
Lastly, we share out c:\program files\microsoft service fabric\bin\servicefabric because that directory contains the PowerShell module installed by the SDK.
When the container starts, we need to do the following:
First, register the module with PowerShell:
Copy-Item C:\ServiceFabricBin C:\windows\system32\WindowsPowerShell\v1.0\modules\ServiceFabric -Recurse
After you do this, Get-Module -ListAvailable will show the ServiceFabric module. However, no exports will be loaded because it's missing a bunch of DLLs. The installer puts those DLLs in the GAC, but the GAC is dumb so let's just put those DLLs in the same directory so the module finds them:
Copy-Item C:\ServiceFabricCode\System.Fabric*.dll C:\windows\system32\WindowsPowerShell\v1.0\modules\ServiceFabric -Recurse
After this, you should be able to run Get-Module -ListAvailable and see the ServiceFabric module fully loaded.
There's one final thing to do. The Deploy-FabricApplication.ps1 script imports the ServiceFabricSDK.psm1 module (see above). But what is $ModuleFolderPath? Well, the script by default looks in the registry for this value, which of course the installer sets for you. We don't want to muck with the registry for our Docker image, so let's just change the script to look at an environment variable instead:
$ModuleFolderPath = $ENV:ModuleFolderPath
Import-Module "$ModuleFolderPath\ServiceFabricSDK.psm1"
Now we can set that environment variable when we run our Docker container (or from our Dockerfile). Obviously, if you didn't want to modify the Deploy-FabricApplication.ps1 file, you could set this at HKLM:\SOFTWARE\Microsoft\Service Fabric SDK\FabricSDKPSModulePath as well. I'm fairly anti-registry so an environment variable (or just hard code if you really don't care) makes more sense to me.
Also note you'll need to import your certificate (Which you can download from the Key Vault in the form of a PFX file) before the script will deploy:
Import-PfxCertificate -Exportable -CertStoreLocation Cert:\CurrentUser\My\ -FilePath C:\Certs\MyCert.pfx
I believe a more production quality version of this would be to copy the required files into the image within your Dockerfile rather than mount them as volumes so the image would be more self contained, but that should be fairly straight forward. Also, I believe the DLLs that were GAC'ed are also available on NuGet, so it could be possible to download all those files through NuGet during the Docker build process.
Also, here's my full Dockerfile which I've successfully deployed an app to Service Fabric using:
# escape=`
FROM microsoft/dotnet-framework:4.7.1
SHELL ["cmd", "/S", "/C"]
# Install Visual Studio Build Tools
ADD https://aka.ms/vs/15/release/vs_buildtools.exe C:\SETUP\vs_buildtools.exe
RUN C:\SETUP\vs_buildtools.exe --quiet --wait --norestart --nocache `
--add Microsoft.VisualStudio.Workload.AzureBuildTools `
|| IF "%ERRORLEVEL%"=="3010" EXIT 0
SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]
# Our Deploy Certs
ADD ./Certs/ C:\Certs\
# Update Path (I forget if this was needed for something)
RUN SETX /M PATH $($Env:PATH + ';C:\ServiceFabricCode')
I'm hoping this helps someone, but more so I'm hoping Microsoft fixes their installer to remove the runtime requirement.
Best way to install Azure service fabric is by creating a poweshell file and call it from dockerfile
PowershellFile:
Start-Process "msiexec" -ArgumentList '/i', 'C:/app/WebPlatformInstaller_amd64_en-US.msi', '/passive', '/quiet', '/norestart', '/qn' -NoNewWindow -Wait;
& "C:\Program Files\Microsoft\Web Platform Installer\WebPICMD.exe" /Install /Products:MicrosoftAzure-ServiceFabric-CoreSDK /AcceptEULA
Dockerfile :
RUN powershell -noexit "& ""./InstallServiceFabric.ps1"""
I'm installing sonarqube on Windows Server 2012.
I have followed the following steps:
Downloaded sonarqube4.4 and extracted to C:\Sonarqube
Downloaded Java JDK 1.7.0_60 and jre 1.7.0_67 as well as jre7
Installed Windows SDK 7 and .NET Framework 4
Navigated to C:\sonar\bin\windows x86-64 and ran StartSonar.bat as an administrator, this ran ok with no output and Ihad to hot ctrl- Z to break
I then ran \windows-x86-64\InstallNTService.bat as an administrator and I am seeing the sonarQube services was launched, but failed to start.
Not sure what the problem is.
I believe you first ran \windows-x86-64\InstallNTService.bat successfully and then StartSonar.bat unsuccessfully (the inverse order of what you describe).
You probably have [this problem]: http://qualilogy.com/fr/wp-content/uploads/sites/2/2013/09/Sonar_ServiceLaunchError2.jpg
Windows could not start the Sonar service on Local Computer.
Error 1067: The process terminated unexpectedly.
In that case, the solution is to change the user/rights to launch the Sonar service: https://qualilogy.com/en/migrate-sonarqube-tomcat-to-windows-service/
Go to the Services window, find the Sonar service, and open the Properties windows to change the user it logs on as to one with sufficient permissions.
I was able to solve this problem by creating a new folder named “Temp” in C:\Windows\System32\config\systemprofile\AppData\Local\
The Log-File will show only
--> Wrapper Started as Service
Cleaning or creating >temp directory C:\Program Files (x86)\SonarQube\sonarqube\temp
<-- Wrapper Stopped
The SonarQube service was launched, but failed to start.
After a long search, I came up to this site http://zen-and-art-of-programming.blogspot.de/2013/03/installing-and-running-sonar-source.html.
Solution:
Navigate to C:\Windows\system32\config\systemprofile\AppData\Local\ and create the directory Temp
2: Set the user rights to full access
3: Run the StartNTService.bat
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?
When I create a new WebAPI project (MVC4) I get the following error.
EntityFramework.5.0.0: Failed to initialize the Powershell host. If your powershell execution policy setting is set to AllSigned, open the package manager console to initialize the host first.
jQuery.1.7.1.1: Failed to initialize the Powershell host. If your powershell execution policy setting is set to AllSigned, open the package manager console to initialize the host first.
After Googling I have found a few answers but nothing that works yet.
Error creating new MVC project - EF and JQuery
This answer seems like it should work for me as my last project was a 7z Command Line app and I might have done something daft with 7zip. But I copy pasted the 7-Zip directory from Program Files to Program Files (86) with no luck.
http://social.msdn.microsoft.com/Forums/en-US/vssetup/thread/c934fed4-e44e-4a06-9e3b-eccb9c8aa8d6
There is an answer here that might work (I haven't tried it) but even if it does work I wouldnt want to do this every time I create a new project.
Is anyone able to help me with this one?
I got around a similar error by running PowerShell as administrator with the command Set-ExecutionPolicy Unrestricted, restarting Visual Studio, and opening the Package Manager Console before what I wanted to do.
Make sure you understand the security implications of doing this first.
http://technet.microsoft.com/en-us/library/ee176961.aspx
Restricted - No scripts can be run. Windows PowerShell can be used only in interactive mode.
AllSigned - Only scripts signed by a trusted publisher can be run.
RemoteSigned - Downloaded scripts must be signed by a trusted publisher before they can be run.
Unrestricted - No restrictions; all Windows PowerShell scripts can be run.
I encountered this issue recently, after re-install VS and install the latest VS update 2, things go well. This works for me at least.
I have a vb6 activex document project and I need to create an msi package (thats what is the requirement since it has to be deployed thru active directory) that runs without any user interface and user intervention. I followed these steps:
I created an msi project using visual studio installer and removed all the user interfaces. Added all the vbd files manually to the project, compiled it. When I run the msi, it intalls all the files without prompts but the application doesn't run.
I created a package using package and deployment wizard, then opened the source code of vb pdw project, commented all the message boxes, assigned default values where required. Then compiled setup.exe file and copied/overwrote it with the setup.exe on the install package created earlier. When I run it from command prompt like this 'setup.exe -s install.log' it installed the application without prompts, works well. And the application runs well after installation.
So I decided to create an msi package using visual studio 2008 and added the above created install package (using package and deployment wizard). In custom action I set the setup.exe to run with '-s install.log' arguments. I need one registry entry that holds the App path, so I added it on the registry settings section.
Another requirement is I need to run another self-extracting exe after the installation. And that self-extractor will look at the above registry entry and extracts (overwrites) the file on the App path.
So using custom action, I set the update.exe to run after the installation.
Now, when I run the msi, it runs well, and after installation it runs the update.exe, everything works well; but only sometimes. I couldn't predict when it works and when it doesn't. When I tried the same msi on few other machines, it worked on some and not on others.
And when I checked the 'Add or Remove programs' there were many entries for this App.
I have been struggling with this msi project for a while and now I feel helpless. I don't know what I'm doing wrong. I would appreciate if anyone could point me in the right direction.
Any other way to create an install package for vb6 activex document project without prompts?
This works for me using MSI to install an ActiveX dll document:
This reply is a bit late, but I also struggled with this for about
a year before getting it to work. The key seems to be in registering the ActiveX
exe or dll when installing on another PC. The following works for me; am only
listing steps for a dll as still haven't succeeded 100% with exes:
Create your ActiveX dll Document (you can have forms with dll just like exe)
Use VB Package and Deployment to gather the necessary files in one place.
Be sure to use the safe VB system files (download a zip file [vb6sp6sys.zip] of them from http://www.jrsoftware.org/iskb.php?vb) in place of those
generated by VB's Package and Deployment wizard.
Use VB to create the small executable (make sure Startup Object is
Sub Main) shown below in the code section. Because Internet Explorer is the "container" for your ActiveX document, this little exe uses a version of it
(IE) to load your UserDocument1.vbd, DEPENDING ON WHICH OS you are using. Windows 7 and, I assume Vista, use a different version of IE by default, which doesn't seem to want to run an ActiveX document. But, in their Program Files (x86) there is a version of IE that will - hence the test on whether the (x86) folder exists or not; if not it assumes this is a lower version of Windows and runs using the normal IE. Call this small executable something like "SilentStartUp_ByOS.exe"
Now the bad news: You need to buy Advanced Installer to use its Professional version, which is needed to extract the registration info from
the native library of your DLL and any included OCXs. There is a free version
of Advanced Installer, but it doesn't have this capability.
Note: There may be other installation packages that will do this also, but
Advanced Installer is the only one I know about. I'm an Inno fan, but couldn't
find any way to do this with Inno.
Include all the files from 2. above, along with the exe created in 3. in
your Install package. Assign an icon to the exe created in 3. using Advanced
Installer and make it a shortcut to start your program.
Be sure to install everything (using the Install Parameters screen) in the AppDataFolder\AnyFolderNameHere instead of the ProgramFilesFolder
for the sake of bypassing Security issues which are very strict on Win7
and Vista, not to mention if installed on a company intranet.
When all is done, because your dll was registered, IE should be able
to start up your ActiveX document.
Code:
Sub Main()
Dim strTemp As String
'ok, it may be Vista or Windows 7...
strTemp = "C:\Program Files (x86)\Internet Explorer\"
If CheckFileFolderExists(strTemp, False) = True Then
'ok, use older version of IEXPLORE to run this on Win7 (or Vista)...
Shell "C:\Program Files (x86)\Internet Explorer\IEXPLORE.EXE " & App.Path & "\UserDocument1.vbd", vbMaximizedFocus
Else
Shell "C:\Program Files\Internet Explorer\IEXPLORE.EXE " & App.Path & "\UserDocument1.vbd", vbMaximizedFocus
End If
End Sub
Function CheckFileFolderExists(strName, fFile) As Boolean
' The fFile variable determines whether you're
' looking for a File (True) or Folder(False)
' The strName variable holds the fully qualified
' path you're looking for
Dim fso
Set fso = CreateObject("Scripting.FileSystemObject")
CheckFileFolderExists = False
If fFile = True Then ' It's a file
If fso.FileExists(strName) = True Then
CheckFileFolderExists = True
Exit Function
End If
Else ' It's a folder/directory
If fso.FolderExists(strName) = True Then
CheckFileFolderExists = True
Exit Function
End If
End If
Set fso = Nothing
End Function