I am using Wix to install a windows service. The service will need to run under a non system/service account that is set up by the user.
Is it possible to have it prompt for the username/password for the service login?
The Community MSI Extensions on GitHub contains a ServiceCredDlg dialog for prompting username and password. According to the docs, it can test the credentials are valid and that user has 'logon as a service' rights.
Yes, but it's not built-in. You can setup a GUI in WiX (which is not too intuitive) where you can prompt for any setting you'll need in later steps.
First, check out how to create a GUI that sets custom properties by following these guidelines, ensuring that your GUI fills properties SERVICEACCOUNT and SERVICEPASSWORD. Then use the ServiceInstall element with those properties as shown here.
WiX doesn't (or at least didn't) have anything nice out of the box for what you are looking for. Best option that I am aware of is to roll-your-own.
https://www.geekproject.com/post/wix-service-account-dialog/
You can set PUBLIC PROPERTIES (uppercase) with the credentials on the command line and use these to install the service.
msiexec.exe /I "setup.msi" /QN USER="username" PASS="password"
A custom action can also be used to retrieve these values from the user during an interactive install, but if you do this remember to make the display of the message obey the setups UILevel value. Showing a message box from a custom action in a silent install is considered a serious setup error:
INSTALLUILEVEL_NONE 2 Completely silent installation.
INSTALLUILEVEL_BASIC 3 Simple progress and error handling.
INSTALLUILEVEL_REDUCED 4 Authored UI, wizard dialogs suppressed.
INSTALLUILEVEL_FULL 5 Authored UI with wizards, progress, errors.
Perhaps the best option is to show the dialog in an interactive install, and refuse to install silently if these properties aren't set on the command line. This is a simple custom action to test the values of the USER and PASS properties.
And obviously it is not recommended to use user accounts to run services.
Related
I have a CA that runs deferred without impersonation in InstallExecuteSequence after PublishProduct.
This CA uses windows impersonation to change context to a local administrative user where the credentials are for queried using a dialog for user input. The elevated requirements are meet, the context is changed and other tasks are performed, however when I try to open a subkey made by the installer for write access in HKLM\SYSTEM\CurrentControlSet\Services\NameOfService\MySubKey, I get an exception related to insufficient access. However I can open for read though?
At this point the service has been installed, the key has been created and other values have been written. The context I am using to modify it is a member of the local Administrators group and the session is elevated as per requirements of the other tasks?
Is this a caveat of the windows installer environment?
For whatever reason, exiting the impersonation back to LocalSystem resolved this. Likely an issue with elevation.
I have an Okuma OSP Machine Controller running Windows XP.
By default it attempts to automatically log on when the machine is turned on.
We have changed the default administrator password and now the auto-log on fails every time.
How can I turn off this feature or update the password so that it succeeds?
Machine Types Effected: Any machine with P200 or P300 control running Windows-XP
4/1/2014: Confirmed the same applies to new OSP-300 Windows 7 controls
2/1/2015: There is another (easier) way to accomplish this on Okuma controls.
This can be done using a utility in the TOOLS directory called the "Auto Logon Setting Tool". This is perfect for anyone uncomfortable with editing the registry.
Tool location:
The utility:
Just choose the user you wish to to be logged on automatically, and click the "Register auto log-on" button.
This feature is enabled from the factory to allow users to get up and running quickly while still having the machine password protected. Because it is recommended to change the default password this is most likely a very common situation.
The automatic login behavior can be changed by editing registry settings.
Click Start, type "regedit" (sans-quotes) in the run box, and press enter.
In the folder structure in the left pane, navigate to the following folder:
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
To turn the feature OFF, change the key value of "AutoAdminLogon" to '0'
Similarly, the default user name and password can be changed by editing the appropriate keys to restore the functionality of the auto login feature.
Reference Microsoft Support article here.
In my WiX projects I have two custom actions, in the same DLL. Both are written in C#.
The first one enumerates which IIS-sites are available on the machine. It runs before the Windows Installer dialogs.
The second one runs after a dialog "select which web-site", i.e. in the Dialog-flow as a result of pressing "Next".
The first one logs nicely to the MSI-logfile.
The second one logs nothing at all.
Why cannot my custom action log during the dialog-part? (The rest of the dialog-part is logging as expected.)
Is there something I can do to enable this logging?
Custom actions can't write to the MSI log when they're invoked using a DoAction control event. It's an MSI limitation.
It's a permissions problem.
IIS web site enumeration requires Administrator privileges, so the first custom action runs in an elevated process. Your second custom action runs in a non-elevated process, so it doesn't have enough permissions to write in your log.
If you create the log in a per-user location, for example the current user desktop, the second action will successfully write in the log.
A solution is to use an elevated process for your second custom action. Another solution is to always create the log in a per-user location.
My coworker is trying to register some COM components (which I wrote) via RegAsm.exe and it says he needs Administrator privileges. His account has admin privileges but he is not logged in as Administrator. Is there a way to use his regular user account and succeed at this task?
I work in an environment/jurisdiction where giving local admin access to all users is simply not possible (legal/compliance/regulations will not allow).
It appears there is no equivalent of this function in .NET world: AtlSetPerUserRegistration
Try this: Using regasm, generate the registry entries with /regfile argument. By default, registry entries should use HKEY_CLASSES_ROOT (HKCR) as a root. Modify the entries (manually, or by script) to use HKEY_CURRENT_USER (HKCU).
Finally, distribute your .NET DLL with the registry script. You can still run regedit without admin rights to register your .NET DLL. Manually from the command line, using a batch file, or a (tiny) separate installation program can handle the registration.
Admin privileges are required to allow Regasm.exe to update the registry. If this is a UAC restriction then create a shortcut on the desktop for cmd.exe and check the "Run this program as an administrator" checkbox. Or change this setting on the Visual Studio Command Prompt shortcut, that's easier.
I think this question belongs elsewhere, but Windows uses least privilege so if he is a user that is both a normal user and an Administrator than he gets normal user privileges. Use runas to make this work or right click the item and "run as administrator"
Why don't you use registration free com? Its only been supported since 2003 and obviates the need for UAC / administrative access to install COM components.
With RegFree COM you can just bundle the COM dlls with the application that uses them as a private assembly - but that doesn't mean they can't be properly installed - either in the registry or in WinSxS by the final deployment install.exe/msi
Subtext wrt the actual query: no - COM registration is in the HKEY_LOCAL_MACHINE key that always requires administrative access.
I lied: Actually you can. If you create a application with no manifest at all, Windows deduces that its an XP era application that expects administrative access to run and will activate a compatibility mode that, amongst other features, redirects write access to HKLM to a writable location under HKCU. So the COM component registration "succeeds" - but is registered for the current user only.
Im not sure why the ability to register for just the current account isn't supported generally outside the compatibility framework.
Check this out: https://gist.github.com/florentbr/6be960752fc852ee99eece6b4acb8ba7
I was trying to do the same thing and was about to give up when I came upon it.
It's a cmd script that will register the SeleniumBasic.dll in the registry without having admin privileges. With a bit of work you should be able to repurpose the code to register your COM components.
Many, many thanks to Florent Breheret for SeleniumBasic and this cmd script to register it!
I am logged into an account that has Administrator privileges. But RegAsm.exe still says it needs Administrator privileges.
[From some notes I have for Windows 2008 R2. Confirm on other Windows operating systems that support UAC. The following assumes that you are permitted to make changes to the Local Security Policy. ]
In its default configuration, User Account Control (UAC) settings give the local Administrator full privileges, but restrict the privileges of other members of the Administrators group. To lift the UAC restrictions on other members of the Administrators group, do the following:
Select Start -> All Programs -> Administrative Tools -> Local Security Policy.
Select Local Policies -> Security Options.
In the right panel, double-click the third entry from the bottom which reads User Account Control: Run all administrators in Admin Approval Mode.
Click Disabled.
Click OK to close the dialog and close the Local Security Policy configuration tool.
Reboot the computer to complete this change to the UAC settings.
I'm handling the Application.UnhandledException event in a WinForms app and need to log exceptions caught there. My app.config is set up to log exceptions to a FileLog and an EventLog.
The problem is that when running as a non-admin user, the EventLog cannot be written to because of a SecurityException - I get the message "The source was not found, but some or all event logs could not be searched."
I understand why - the user does not have permission to create the EventLog source, but the question is how should this source be created? As I see it, I could either:
1) Create the EventLog source with my installer, as this is running as admin. How to do this?
2) Create from within my app, by somehow elevating permissions? But this would give the UAC prompt on Vista.
What's the best practice for creating a Windows Application EventLog source on a client machine?
thanks
The most common way to do this is your Option 1.
How you do it depends on your installer package, but you need to:
Ensure your installer runs with elevated permission.
Write a single entry to that event log source, OR
Create the registry key for your event source directly
When your installer writes to the event log, the source will be created and will be available for non-administrators.
With WiX, (Windows Installer Xml) you can reference this post for directly creating the event source registry entry.