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.
Related
I'm trying to create an event source like this:
EventLog.CreateEventSource(myApplicationName,"Application")
My application is marked as Full Trust under ClickOnce, but I still get this SecurityException:
The source was not found, but some or all event logs could not be searched. To create the source, you need permission to read all event logs to make sure that the new source name is unique. Inaccessible logs: Security.
The documentation for this method indicates that you must either be a local admin or mark the application as Full Trust. What am I doing wrong?
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.
In my organization we are deploying our components using Microsoft TFS. The NServiceBus components are deployed as Windows Service by the BuildPortal.It typically creates the automated MSI packages and deploys it on the target servers. To deploy the MSI packages, the build portal uses the Service account (the Administrator/SuperUser). The NServiceBusHost will not run with the same service account, either it will use the System account or different Service account, which has restricted permission on the server and the account will not be part of the Administrator group.
In short, the Host /install command runs with different account than the actual NServiceBusHost execution. During the install, all the required queues are created by the installer (by using NServiceBus.Integration profile). Now, the problem is, since the queue created by different account than the original service account, it throws the following error.
Message:Could not create queue error#xxxxxxx01 or check its existence. Processing will still continue.
NServiceBus.Utils.MsmqUtilities.CreateQueueIfNecessary(:0)
System.Messaging.MessageQueueException (0x80004005): Access to Message Queuing system is denied.
at System.Messaging.MessageQueue.SetPermissions(AccessControlList dacl)
at NServiceBus.Utils.MsmqUtilities.SetPermissionsForQueue(String queue, String account)
at NServiceBus.Utils.MsmqUtilities.CreateQueueIfNecessary(Address address, String account)
To resolve the above error, we tried to use the INeedToInstallSomething. But, there are no proper documentation/sample on how to use or what to use inside the Install() method. When we call the Configure.Instance.ForInstallationOn().Install() the installer is not creating the queues as expected. All we wanted is, to get the list of dependent queues of current installer & set the permission something like this >> messageQueue.SetPermissions(serviceAccount, MessageQueueAccessRights.FullControl)
Is this possible to get all the dependent queues for the current Host and assign the permission during the Host install only.
NOTE:
We dont want to move this logic outside of the host for now. Yes,
having a simple PSS may help to reslove this issue.
We have to use the restricted account to run the Host which can't be a Administrator.
I would try either INeedToInstallInfrastructure<T> and set the permissions there, or this may be like the perf counters which uses IWantToRunBeforeConfigurationIsFinalized. You may need the latter and I'm not sure what order if any is used for INeedToInstallInfrastructure<T>.
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.