I have an application which runs as window service. Application hosted using the topself. In wix installer, we hosts it using the command based custom action. and in application startup we use to host as RunAsLocalSystem().
In .wxs file:
<CustomAction Id="RunTopShelfServiceInstall" Directory="INSTALLFOLDER" Execute="deferred" Return="ignore" Impersonate="no" ExeCommand="[INSTALLFOLDER]Management.exe install" />
2.in Startup.cs
HostFactory.Run(x =>
{
x.UseSerilog();
var version = Assembly.GetExecutingAssembly().GetName().Version.ToString();
x.Service<ManagementService>(s =>
{
s.ConstructUsing(name => new ManagementService());
s.WhenStarted(tc => tc.StartAsync().ConfigureAwait(false));
s.WhenStopped(tc => tc.StopAsync().ConfigureAwait(false));
});
x.RunAsLocalSystem();
x.StartAutomatically();
x.SetDescription($"management service");
x.SetDisplayName($"Management");
x.SetServiceName($"Management");
x.EnableServiceRecovery(option =>
{
option.RestartService(0);
});
});
On Upgrade scenario, It asks for the new username and password. I need to implement a solution to keep the same service account credentials for upgrade. Meaning, On upgrade it should not asks for credential, only at first time installation we need to provide it.
Please suggest.
Related
I am trying to configure Windows authentication on a subroute only in my ASP.NET Core MVC app.
My problem is that when I add
services.AddAuthentication().AddNegotiate()
I get an error
The Negotiate Authentication handler cannot be used on a server that directly supports Windows Authentication.
which lead me to adding web.config as the docs explained:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<security>
<authentication>
<anonymousAuthentication enabled="false" />
<windowsAuthentication enabled="true" />
</authentication>
</security>
</system.webServer>
</location>
</configuration>
and the error goes away. However, now the Windows authentication is popping up on each request.
I tried changing the location path to .testendpoint but that then throws the original error at the base path.
So is it possible and how do I make such only /testendpoint will ask for Windows authentication and the remaining of the application will work with whatever other auth I configured in my ASP.NET Core app?
Another way using endpoint routing:
We have an application schema for the application that will be used all over the app called eavfw.
Using a custom endpoint here called login/ntlm with metadata new AuthorizeAttribute(NegotiateDefaults.AuthenticationScheme) its only allowed to be visited by a valid windows authenticated user.
Here we then create the user in our DB using its AD username.
endpoints.MapGet("/.auth/login/ntlm", async httpcontext =>
{
var loggger = httpcontext.RequestServices.GetRequiredService<ILogger<Startup>>();
var windowsAuth = await httpcontext.AuthenticateAsync(NegotiateDefaults.AuthenticationScheme);
if (!windowsAuth.Succeeded)
{
loggger.LogWarning("Not authenticated: Challening");
}
if (windowsAuth.Succeeded)
{
loggger.LogWarning("Authenticated");
var name = string.Join("\\", windowsAuth.Principal.Claims.FirstOrDefault(c => c.Type.EndsWith("name")).Value.Split("\\").Skip(1));
var context = httpcontext.RequestServices.GetRequiredService<DynamicContext>();
var users = context.Set<SystemUser>();
var user = await context.Set<SystemUser>().Where(c => c.PrincipalName == name).FirstOrDefaultAsync();
if (user == null)
{
user = new SystemUser
{
PrincipalName = name,
Name = name,
// Email = email,
};
await users.AddAsync(user);
await context.SaveChangesAsync();
}
var principal = new ClaimsPrincipal(new ClaimsIdentity(new Claim[] {
new Claim(Claims.Subject,user.Id.ToString())
}, "ntlm"))
{
};
await httpcontext.SignInAsync("ntlm",
principal, new AuthenticationProperties(
new Dictionary<string, string>
{
["schema"] = "ntlm"
}));
httpcontext.Response.Redirect("/account/login/callback");
}
}).WithMetadata(new AuthorizeAttribute(NegotiateDefaults.AuthenticationScheme));
using a auxility authentication cookie, we can now make it such that specific areas of our app that requires windows authentication, it can simply rely on Authorize("ntlm") as it automatically forward the authenticate call to check if already signin, and it as part of the signin call in the endpoint above actually sign in eavfw.external before it redirects to the general account callback page that will do some final validation before signing in eavfw from the eavfw.external cookie
services.AddAuthentication().AddCookie("ntlm", o => {
o.LoginPath = "/.auth/login/ntlm";
o.ForwardSignIn = "eavfw.external";
o.ForwardAuthenticate = "eavfw";
});
So there are a few ways to extend and use the authentication system in auth core depending on how MVC framework heavy your application is.
Just thought I'd share this tidbit of information:
First off, just because you installed Windows Authentication with Server Manager, doesn't mean it's enabled in IIS. It's NOT enabled, by default.
You have to open IIS Manager, click on your server (NOT the website - the name of the server machine hosting IIS). Then click on Authentication - you will see "Windows Authentication" is disabled. Enable it. Now it will work.
Check this is correctly set first, before making other config changes. The default project for dotNet5 and dotNet6 will work w/o any modifications if IIS is correctly configured for Windows Authentication.
In order to have a certain page/action method secured via Windows authentation, specify the corresponding authentication scheme in the action methods Authorize attribute.
[Authorize(AuthenticationSchemes = IISServerDefaults.AuthenticationScheme)]
public IActionResult UsingWindowsAuthentication()
Make sure to have Windows authentication enabled on your website.
In order to use other authentication schemes, e.g. "Individual Accounts", anonymous authentication is also enabled.
The controllers and/or action methods that must not use Windows Authentication have the default scheme specified.
For example, for an ASP.NET Core MVC project that uses the out of the box "Individual Accounts" authentication type as default authentication method, that is Identity.Application.
[Authorize(AuthenticationSchemes = "Identity.Application")]
public IActionResult Index()
See the documentation about how to set up and configure multiple authentication schemes.
I have this problem with wix installer not installing our application IISversion >=10. It works on IISVersion <10.
I found this link on github. https://github.com/wixtoolset/issues/issues/5276
This link suggests adding a custom action which returns ActionResult.Success if IISRegistryversion is >= IISRequiredVersion.
But I am getting the following error. The error happens after this in the log
Doing action: LaunchConditions
Action start 12:46:02: LaunchConditions.
Either the variable is not being set or custom action is not being called.
I have some logging in the custom action but its not logging anything even with verbose on.
How do make sure the launch condition/ custom action is being called before this condition is evaluated? Can anyone suggest please?
This is how Product.wxs looks
<InstallExecuteSequence>
<Custom Action="CA.DS.CreateScriptDirCommand" Before="InstallFinalize">
<![CDATA[NOT Installed AND (&Feature.DatabaseServer.Database = 3)]]>
</Custom>
<Custom Action="Iis.CheckInstalledVersion.SetProperty" Before="LaunchConditions" >
<![CDATA[NOT Installed AND &Feature.WebServer.WebServices = 3]]>
</Custom>
<Custom Action="Iis.CheckInstalledVersion" After="Iis.CheckInstalledVersion.SetProperty" >
<![CDATA[NOT Installed AND &Feature.WebServer.WebServices = 3]]>
</Custom>
</InstallExecuteSequence>
<Condition Message="This application requires IIS [Iis.RequiredVersion] or higher. Please run this installer again on a server with the correct IIS version.">
<![CDATA[Iis.IsRequiredVersion > 0]]>
</Condition>
<Fragment>
<CustomAction Id='Iis.CheckInstalledVersion.SetProperty' Property='Iis.CheckInstalledVersion' Execute='immediate' Value='' />
<!--Note: Changed "Execute" from "deferred" to "immediate", to avoid error "LGHT0204: ICE77: Iis.CheckInstalledVersion is a in-script custom action. It must be sequenced in between the InstallInitialize action and the InstallFinalize action in the InstallExecuteSequence table"-->
<!--Note: Changed "Impersonate" from "no" to "yes", to avoid warning "LGHT1076: ICE68: Even though custom action 'Iis.CheckInstalledVersion' is marked to be elevated (with attribute msidbCustomActionTypeNoImpersonate), it will not be run with elevated privileges because it's not deferred (with attribute msidbCustomActionTypeInScript)"-->
<CustomAction Id='Iis.CheckInstalledVersion' BinaryKey='B.WixCA' DllEntry='CheckInstalledIISVersion' Execute='immediate' Return='check' Impersonate='yes' />
<Component
</Component>
</Fragment>
[CustomAction]
public static ActionResult CheckInstalledIISVersion(Session session)
{
try
{
session.Log("* Starting to check installed IIS version");
const int IisRequiredVersion = 7;
string IISMajorVersionFromRegistry = session["IISMAJORVERSION"];
session.Log(string.Format("*!*! DEBUG; CheckInstalledIisVersion; IIS major version: {0}", IISMajorVersionFromRegistry));
string iisMajorVersionNumeric = IISMajorVersionFromRegistry.Replace("#", string.Empty);
int iisMajorVersion = int.Parse(iisMajorVersionNumeric, CultureInfo.InvariantCulture);
bool isRequiredVersion = iisMajorVersion >= IisRequiredVersion;
// Setting the required version as a custom property, so that it can be used in the condition message
session["IIs.RequiredVersion"] = IisRequiredVersion.ToString(CultureInfo.InvariantCulture);
// Setting the results of the check as "bool"
session["Iis.IsRequiredVersion"] = isRequiredVersion ? "1" : "0";
return ActionResult.Success;
}
catch (Exception ex)
{
session.Log(string.Format("CheckInstalledIisVersion; Error occured SC: {0}", ex.Message));
return ActionResult.Failure;
}
}
It works without the condition. The condition gets executed before
The feature check Feature.WebServer.WebServices = 3 isn't going to work because the feature "to be installed" state isn't set until after costing (and often choosing the feature in the feature dialogs). So the CA isn't being called.
You probably need to rethink this and force the check for IIS after CostFinalize, and then perhaps warn then that IIS is not installed/running etc. So you'd do the search for IIS unconditionally to set the property and not use it as a launch condition. Then give the warning if &Feature.WebServer.WebServices = 3 and the IIS version is too low.
See feature action condition documentation and the reference to CostFinalize:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa368012(v=vs.85).aspx
I have to check if some windows features are enabled beore installing my software.
I can check it or install it using dism command line tool.
I create a custom action to do this, but is there a way to do it in a "WIX native way" ?
<Property Id="dism" Value="dism.exe" />
<CustomAction Id="InstallMSMQContainer" Property="dism" ExeCommand=" /online /enable-feature /featurename:MSMQ-Container /featurename:MSMQ-Server /featurename:MSMQ-ADIntegration" Return="check" Impersonate="yes" Execute="oncePerProcess"/>
<InstallUISequence>
<Custom Action="InstallMSMQContainer" After="CostFinalize" Overridable="yes">NOT Installed</Custom>
</InstallUISequence>
The problem is that command launch a command prompt, which is very ugly for end user.
How can I make it nicer? I don't know if i need a bootstraper to do this (like installing the .NET Framework).
Is there any extention to manage that things ?
I'm now using WIX 3.7.
David Gardiner's answer hinted at the correct solution in my case. Creating your own custom action is not necessary. Here is how to do it for a 64 bit installation of Windows:
First determine if MSMQ is installed:
<Property Id="MSMQINSTALLED">
<RegistrySearch Id="MSMQVersion" Root="HKLM" Key="SOFTWARE\Microsoft\MSMQ\Parameters" Type="raw" Name="CurrentBuild" />
</Property>
Declare your custom actions. You need two. One to set a property to the path to dism, and another to execute it:
<CustomAction Id="InstallMsmq_Set" Property="InstallMsmq" Value=""[System64Folder]dism.exe" /online /enable-feature /featurename:msmq-server /all" Execute="immediate"/>
<CustomAction Id="InstallMsmq" BinaryKey="WixCA" DllEntry="CAQuietExec64" Execute="deferred" Return="check"/>
Finally specify the custom actions in the install sequence:
<InstallExecuteSequence>
<Custom Action="InstallMsmq_Set" After="CostFinalize"/>
<Custom Action="InstallMsmq" After="InstallInitialize">NOT REMOVE AND NOT MSMQINSTALLED</Custom>
</InstallExecuteSequence>
Because this can take a little bit of time I've added the following to update the installer status text:
<UI>
<ProgressText Action="InstallMsmq">Installing MSMQ</ProgressText>
</UI>
You can also specify a rollback action if you want to remove MSMQ on installation failure.
You might consider the Quiet Execution Custom Action
The way I do it is by creating a DTF custom action that calls the dism.exe process. You get the same result and no command prompt is launched.
[CustomAction]
public static ActionResult RunDism(Session session)
{
session.Log("Begin RunDism");
string arguments = session["CustomActionData"];
try
{
ProcessStartInfo info = new ProcessStartInfo();
info.FileName = "dism.exe";
session.Log("DEBUG: Trying to run {0}", info.FileName);
info.Arguments = arguments;
session.Log("DEBUG: Passing the following parameters: {0}", info.Arguments);
info.UseShellExecute = false;
info.RedirectStandardOutput = true;
info.CreateNoWindow = true;
Process deployProcess = new Process();
deployProcess.StartInfo = info;
deployProcess.Start();
StreamReader outputReader = deployProcess.StandardOutput;
deployProcess.WaitForExit();
if (deployProcess.HasExited)
{
string output = outputReader.ReadToEnd();
session.Log(output);
}
if (deployProcess.ExitCode != 0)
{
session.Log("ERROR: Exit code is {0}", deployProcess.ExitCode);
return ActionResult.Failure;
}
}
catch (Exception ex)
{
session.Log("ERROR: An error occurred when trying to start the process.");
session.Log(ex.ToString());
return ActionResult.Failure;
}
return ActionResult.Success;
}
DISM parameters are set via the custom action data.
Hi I have these two binary files:
<Binary Id="Sentinel" SourceFile="sentinel_setup.exe"/>
<Binary Id="Hasp" SourceFile="HASPUserSetup.exe"/>
And I would like to start them on a button click like so:
<CustomAction Id="LaunchHasp" BinaryKey="Hasp" ExeCommand="" Return="asyncWait" />
<CustomAction Id="LaunchSentinel" BinaryKey="Sentinel" ExeCommand="" Return="asyncWait"/>
<Publish Event="DoAction" Value="LaunchHasp">1</Publish>
But it doesn't work, It only works when I run the installer from the command line with elevated privileges. What am I doing wrong? Thanks
Or can someone tell me how I could extract the file from the binary table using a c++ custom action as I cannot get it working at all..:(
Immediate custom actions doesn't have elevated privileges. You should use deffered custom actions for such needs. Any action that make changes to the destimation environment should be deffered. For more details read this article: http://bonemanblog.blogspot.com/2005/10/custom-action-tutorial-part-i-custom.html
<CustomAction Id="LaunchHasp" Impersonate="no" Execute="deferred" BinaryKey="Hasp" ExeCommand="" Return="asyncWait" />
Though deffered custom actions are executed during installation phase, not on button click. Revise your installer logic. As I understand, your exe file "sentinel_setup.exe" changes the system, so should be scheduled between InstallInitialize and InstallFinalize events in InstallExecuteSequence
I would recommend adding a checkbox, that user should mark to install your "Hasp" (or installer Feature which user should select in the feature tree). And add deffered custom action with condition on this checkbox state.
Sometimes it is really required to launch admin actions during or before installer UI sequence. In this case you need to create a setup bootstrapper which asks for permission elevation and does required actions before running MSI process. To ask for permissions you need to add application manifest to your bootstrapper project. My bootstrapper is quite simple, but works in many cases. It is Windows application (though without any Windows forms - it allows to hide console window) which contains only icon, application manifest and small code file:
using System;
using System.Diagnostics;
using System.IO;
using System.Linq;
using System.Text;
using System.Windows.Forms;
namespace SetupBootstrapper
{
class Program
{
[STAThread]
static void Main(string[] args)
{
var currentDir = AppDomain.CurrentDomain.BaseDirectory;
var parameters = string.Empty;
if (args.Length > 0)
{
var sb = new StringBuilder();
foreach (var arg in args)
{
if (arg != "/i" && arg != "/x" && arg != "/u")
{
sb.Append(" ");
sb.Append(arg);
}
}
parameters = sb.ToString();
}
bool isUninstall = args.Contains("/x") || args.Contains("/u");
string msiPath = Path.Combine(currentDir, "MyMsiName.msi");
if(!File.Exists(msiPath))
{
MessageBox.Show(string.Format("File '{0}' doesn't exist", msiPath), "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
return;
}
string installerParameters = (isUninstall ? "/x" : "/i ") + "\"" + msiPath + "\"" + parameters;
var installerProcess = new Process { StartInfo = new ProcessStartInfo("msiexec", installerParameters) { Verb = "runas" } };
installerProcess.Start();
installerProcess.WaitForExit();
}
}
}
We have a few MSI packages (generated by WIX) that install WCF services. Most of these services need net.tcp for their endpoint bindings.
I'd like to make our deployment life easier and automate the process of adding net.tcp.
I already know the WixIisExtension.dll and make use of its useful functions (create web site, virt. directory, etc.).
Can I use the WixIisExtension to enable the net.tcp protocol?
If not, how can I achieve that?
Add a new Project to your Setup Solution (Windows Installer XML -> C# Custom Action Project)
In this Project add a reference to the Assembly Microsoft.Web.Administration, which can be found here: C:\Windows\System32\inetsrv and is required to add the protocols.
My Custom Action looks like this:
using System;
using System.Linq;
using Microsoft.Deployment.WindowsInstaller;
using Microsoft.Web.Administration;
namespace Setup.CustomAction.EnableProtocols
{
public class CustomActions
{
[CustomAction]
public static ActionResult EnableProtocols(Session session)
{
session.Log("Begin EnableProtocols");
var siteName = session["SITE"];
if (string.IsNullOrEmpty(siteName))
{
session.Log("Property [SITE] missing");
return ActionResult.NotExecuted;
}
var alias = session["VIRTUALDIRECTORYALIAS"];
if (string.IsNullOrEmpty(alias))
{
session.Log("Property [VIRTUALDIRECTORYALIAS] missing");
return ActionResult.NotExecuted;
}
var protocols = session["PROTOCOLS"];
if (string.IsNullOrEmpty(protocols))
{
session.Log("Property [PROTOCOLS] missing");
return ActionResult.NotExecuted;
}
try
{
var manager = new ServerManager();
var site = manager.Sites.FirstOrDefault(x => x.Name.ToUpper() == siteName.ToUpper());
if (site == null)
{
session.Log("Site with name {0} not found", siteName);
return ActionResult.NotExecuted;
}
var application = site.Applications.FirstOrDefault(x => x.Path.ToUpper().Contains(alias.ToUpper()));
if (application == null)
{
session.Log("Application with path containing {0} not found", alias);
return ActionResult.NotExecuted;
}
application.EnabledProtocols = protocols;
manager.CommitChanges();
return ActionResult.Success;
}
catch (Exception exception)
{
session.Log("Error setting enabled protocols: {0}", exception.ToString());
return ActionResult.Failure;
}
}
}
}
Please note that I am assuming three properties here: SITE, VIRTUALDIRECTORYALIAS & PROTOCOLS
Build the solution now. In the background, WiX creates two assemblies %Project%.dll and %Project%.CA.dll. The CA.dll includes the depending Microsoft.Web.Administration automatically.
Then in your WiX Setup Project include a reference to the new Custom Action Project. The reference is required for referencing the %Projet%.CA.dll.
Edit the product.wxs
First add the properties somewhere inside the product element:
<!-- Properties -->
<Property Id="SITE" Value="MySite" />
<Property Id="VIRTUALDIRECTORYALIAS" Value="MyVirtDirectoryAlias" />
<Property Id="PROTOCOLS" Value="http,net.tcp" />
Below add the binary element:
<!-- Binaries -->
<Binary Id="CustomAction.EnableProtocols" SourceFile="$(var.Setup.CustomAction.EnableProtocols.TargetDir)Setup.CustomAction.EnableProtocols.CA.dll" />
Note that you have to add the CA.dll.
Below add the Custom Action:
<!-- Custom Actions -->
<CustomAction Id="EnableProtocols" BinaryKey="CustomAction.EnableProtocols" DllEntry="EnableProtocols" Execute="immediate" Return="check" />
And finally the Installation Sequence where you want the execution to take place.
<!-- Installation Sequence -->
<InstallExecuteSequence>
<Custom Action="EnableProtocols" After="InstallFinalize">NOT Installed</Custom>
</InstallExecuteSequence>
that's all. Should work.
Thanks to Darin Dimitrov for providing the links above.
Here is the right way to do this in WIX (assuming you are installing on a 64-bit operating system - if not at a guess I'd say change CAQuietExec64 to CAQuietExec although this is untested):
Get a reference to appcmd.exe:
<Property Id="APPCMD">
<DirectorySearch Id="FindAppCmd" Depth="1" Path="[WindowsFolder]\system32\inetsrv\">
<FileSearch Name="appcmd.exe"/>
</DirectorySearch>
</Property>
Define the following custom actions (the properties [WEB_SITE_NAME] and [WEB_APP_NAME] can be populated elsewhere in your installer; or to test you can hard-code them):
<CustomAction
Id="SetEnableNetTCPCommmand"
Property="EnableNetTCP"
Value=""[APPCMD]" set app "[WEB_SITE_NAME]/[WEB_APP_NAME]" /enabledProtocols:http,net.tcp"/>
<CustomAction
Id="EnableNetTCP"
BinaryKey="WixCA"
DllEntry="CAQuietExec64"
Execute="deferred"
Return="ignore"
Impersonate="no" />
Now in the InstallExecuteSequence add
<InstallExecuteSequence>
...
<Custom Action="SetEnableNetTCPCommmand" After="InstallExecute">APPCMD AND NOT Installed</Custom>
<Custom Action="EnableNetTCP" After="SetEnableNetTCPCommmand">APPCMD AND NOT Installed</Custom>
...
</InstallExecuteSequence>
And if all is well in the world that will now update the protocols.
You may take a look at this article on MSDN. There's a section at the end which illustrates how to use the managed API to achieve configure a WAS enabled service. I am not familiar with Wix but you could probably use and plug this code into some custom deployment step.
This can't be done using the standard WiXIIsExtension, as far as I know. Thus, the only option you have is a custom action.
You can also find this thread interesting - it gives a hint how to achieve the similar thing in MSBuild script, but you should be able to translate it to custom action easily.
Good luck!