I'm adding WMI publishing to a .net framework 3.5 based windows service that is running under the 'network service' account.
According to a document I came across on MSDN, the 'network service' account should by default have WMI publishing permissions. ("By default, the following users and groups are allowed to publish data and events: ... Network Service, ...")
However, when the service calls Instrumentation.Publish(myStatusClassInstance), it throws a DirectoryNotFoundException;
System.IO.DirectoryNotFoundException was unhandled
Message: Could not find a part of the path 'C:\Windows\system32\WBEM\Framework\root\MyWMINamespace\MyService_SN__Version_1.0.3686.26280.cs'.
..so it looks like System.Management.Instrumentation tries to generate code on the fly, and when running under network service it targets a directory where network service has no permissions.
What is the best fix/workaround for this? Can I override the code-gen target dir in app.config or in code? I don't want to have to fiddle around with file system permissions when deploying the service...
Update: I think this is a 'feature' where older FX code clashes with newer security settings in Win7. Internally the WMI managed classes retrieves the WMI installation directory from registry, and uses that as the output path for generated code. Unfortunately a lot of users are not allowed to (or supposed to) write stuff under %SystemRoot%... ...I filed a connect bug (#530392) to see if MSFT can bring any clarity and/or provide a fix or workaround.
Update 2: I'm guessing that for normal user accounts this is not an issue, because UAC virtualization will kick in and store the files elsewhere. However, apparently the 'network service' account is not covered by UAC virtualization..(?)
Update 3: Added 550pt bounty. Simple constraints: .net framework 3.5 based windows service, running as network service, need to be able to publish data through WMI using System.Management.Instrumentation on Win7 and Win2008[RTM & R2] with default permissions/security settings and without resorting to modifying framework internal/private members using reflection. 'Out-of-the-box' but clean solutions welcome. Will open a second related bounty-Q as a placeholder for another 550pt if SO allows.
Bounty update: I intend to double the bounty for this Q through a second hand-in-hand question that will serve as a bounty placeholder:
https://stackoverflow.com/questions/2208341/bounty-placeholder ( <-- Apparently this was not allowed, so the bounty placeholder question got closed by the SO etiquette police.)
Update 4: This gets better and better. I noticed that installutil was writing the missing files to c:\windows\syswow64...etc..., so I realized that I was using the 32-bit version of installutil to install the service, but the service was running as a 64-bit process. The obvious side effect was that code generated when installutil was running ended up under syswow64 (the 32-bit system directory), while the service was looking for it under the 64-bit system directory (system32). (<-- off topic, but I really like how MSFT managed to switch around the names there... :) ).
So I tried installing the service with the 64-bit version of installutil. That failed miserably with permission errors in the %sysroot%\wbem\framework...etc... path. Next I recompiled the service as x86 and registered it again using the 32-bit version of installutil. That resulted in an entirely new exception:
System.Exception: The code generated for the instrumented assembly failed to compile.
at System.Management.Instrumentation.InstrumentedAssembly..ctor(Assembly assembly, SchemaNaming naming)
at System.Management.Instrumentation.Instrumentation.Initialize(Assembly assembly)
at System.Management.Instrumentation.Instrumentation.GetInstrumentedAssembly(Assembly assembly)
at System.Management.Instrumentation.Instrumentation.GetPublishFunction(Type type)
at System.Management.Instrumentation.Instrumentation.Publish(Object instanceData)
at SomeService.InstanceClass.PublishApp(String name) in e:\work\clientname\SomeService\SomeService\WMIProvider.cs:line 44
at SomeService.SomeServiceService..ctor() in e:\work\clientname\SomeService\SomeService\SomeServiceService.cs:line 26
at SomeService.Program.Main() in e:\work\clientname\SomeService\SomeService\Program.cs:line 17
...getting closer...
I believe the problem is not with publishing data, but with registering that type in WMI for the first time.
If you examine the System.Management.Instrumentation code in reflector, or some other disassembler, you'll see that wen the assembly that is about to publish hasn't been registered, then the code will try to register the assembly and save the assembly info in a specially named sub directory under the WBEM installation folder.
I suspect that if you run code to publish the WMI data as an administrator first, it would register the assembly and then the Network Service account would have the permissions to do the normal publishing.
Have you inspected your assembly with the installutil? That should give you a log of the installation issues. (But since you can't run it as the Network Service account, it might not show the problem you're having.)
Also, are you sure this service must be run under the Network Service account?
Because of the vulnerability risk in running Windows services in privileged accounts, Microsoft has made these special service accounts with some limitations, which were strengthened in Vista and Win7. Since Vista, Microsoft has limited the number of services running under this account in favor of less-privileged ones (see this article). The Network Service account (aka "NT AUTHORITY\NETWORK SERVICE") can access the network (acting as the local machine account PCNAME$), but it has reduced rights on the local machine (unlike the Local System account).
Have you checked the WMI security permissions for the branch your assembly is using? Run wmimgmt.msc and dig in... When I did a quick check of some random branches, I could see that the Network Service account did not have write rights.
Lastly, I would suggest using Sysinternals' ProcMon, which would allow you to filter to just that process and see if there are any Access Denied errors in file or registry settings. This tool has solved many problems for me over the years.
Not sure if you raised it or someone else but please have a look:
http://connect.microsoft.com/VisualStudio/feedback/details/530392/wmi-publishing-fails-on-permission-error-please-provide-a-way-to-override-codepath-in-system-management-instrumentation-schemanaming-in-app-config-web-config
This may help you to understand the root cause of the issue better
Related
A customer installing my companies software package has no problem installing the package silently when running as an admin account. The software and the service both install correctly and start up post installation. However - they need to push this application to all the computers in a particular group.
They are using SCCM (I do not know the version) and the software package is a InstallShield .exe packaged .msi.
When they try to use the NT Authority\System user to push the package to their test device, the installation fails soon after the 3rd party software package that is included completes. The error log displays that it is a SDDL error 1943. Any idea why this would occur on the NTA\System account and not on a local admin account for a given machine?
The silent install string we are using is setup.exe /s /v" /qn AgreeToLicense=Yes SetupType=Typical"
I'm not a dev, so I dont have direct access to any code in the software, simply a tier 3 tech support working with customers.
Sounds like your MSI is using the MsiLockPermissionsEx table to specify an SDDL string on some resource its installing or configuring (either file, directory, service or registry entry). Either the SDDL string is misconfigured (unlikely if it works from one account but not another) or the ACL on the target directory/service/registry key have become corrupted, which isn't completely unheard of.
You could try getting the customer to deploy a domain account as local admin to the computers and then set SCCM to run the package with this account. I wouldn't recommend this though as it carries inherent security risks of its own.
I'm afraid this may be one that your developers (or whoever created the MSI) need to work out with the customers to find out which resources are at fault and progress the diagnosis.
Sorry I couldn't be of further help.
I think I have found the issue. During install the .msi writes a file to the desktop to be read for configuration settings for the service as being installed. I had the file (and I am sure the customer did as well) already written to the desktop when I tried to invoke the System User for install. This does seem to be an ACL issue, in reference to the System User read/writing to a local user desktop. When the file was deleted, I received error 1406, that it could not write the value of a key. Looking on the desktop, the file had also never been written to the local desktop. When the file was already there (as such with a previous install) I get the error in the original post. At this point I am moving forward testing this as an ACL error and notifying the devs of my findings.
I have a simple msi written in WiX that installs a native NT service. After I have made some changes in the msi it fails at StartServices standard action with the error "service failed to start, verify you have sufficient privileges". If I press Ignore and start the service manually then it start successfully. The problem is definitely not in insufficient privileges. How can I diagnose/debug such issues? The verbose logs of the Windows Installer seem to not contain any helpful information.
The installer won't have any useful information because the error is only surfaced by the installer. Here's how I approach this.
Comment out the ServiceControl element so the installer doesn't try to start the service.
Run installer and all it to finish.
Manually start the service.
If the service starts, this indicates some type of race condition. One common scenario is the service has a dependency on a file being installed to the GAC or WinSXS. The installer puts these files there using the PublishAssemblies standard action. However since the GAC and WinSXS APIs don't support transational installation, PublishAssemblies waits until the commit phase to perform the work. This is after the installer attempts to start the service. Another common scenario would be if you had some custom action that was installing or configuring something that the service needed and you were doing it to late in the installation.
If the service still won't start, this generally rules out race conditions. You have to profile the service itself. Use tools such as depends, ildasm (if .net) and processexplorer (filemon / regmon ) to try to discover what the missing dependencies are. Update the installer then rinse and repeat.
As you've found, the Windows Installer does not provide useful information when it fails to start a service. However, when the dialog is displayed the machine is in the perfect state to determine what is going wrong. So, rather than cancel the install, start debugging. Try to start the service and see if that gives you more information. If not, break out the debugger and go to town.
I basically follow the process described in this FireGiant KB Article. This is the most direct approach to figuring out why the service fails to start. It's too bad the Windows Installer just couldn't provide better messages itself.
I've recently got a new Mac laptop and am running VS2010 in a Parallels virtual machine. It's mostly working out well for me, but I'm having some problems with debugging specific project types, related to the fact that the projects are being accessed via a network share. Test projects don't run because the test runner can't load the tests' DLL. Web projects fail to run in the Visual Studio mini web server, throwing the following exception:
'An error occurred loading a configuration file: Failed to start monitoring changes to path\to\web.config'.
I've spent the evening trawling the web with little luck on this. After reading these two posts, I tried out the usual CasPol changes, but then found this post from one of the early VS2010 betas indicating that CasPol is no longer needed/supported in .NET 4.0 and VS2010.
The network share is accessible via both a mapped drive and the UNC path. The host for the UNC path is .pfs; according to this post Windows treats host names starting with a dot as originating in the Internet Zone.
The virtual machine runs its applications under the administrator account, which appears to have all the necessary permissions on the network share to create, read, write and delete files and folders. I say "appears to have" as I can't view the Security Properties of the appropriate folder via Explorer: the Security tab just isn't present.
Has anyone managed to successfully load and debug web and test projects from a network share in VS2010?
UPDATE: I tried loading the solutions in VS2010 on a separate native Windows machine using the IP address of my MacBook, with mixed results. The test project again failed to run with the error:
Error loading \\192.168.0.4\alastair\Code\project\bin\Debug\Tests.dll: Could not load file or assembly 'file://\\192.168.0.4\alastair\Code\project\bin\Debug\Tests.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
However, the ASP.NET MVC project runs correctly as expected in this setting, and I get exactly the same results here if I use the NETBIOS name of the MacBook.
Of course, in order to do this, I had to enable SMB sharing in Snow Leopard, which wasn't required to access the location in my Parallels VM. Maybe there's some setting in Parallels that I need to tweak to change permissions on the share?
I've also flagged this question for the moderators to request it be moved to StackOverflow; I think it might be a more appropriate forum than SuperUser.
Try setting <loadFromRemoteSources enabled="true"/> under the runtime element of devenv.exe.config, as suggested in the answer to this question. It fixed the issue for me... Visual Studio still warns me when loading a project from the share, but running tests now works.
This assumes the issue is really with Windows "treat[ing] host names starting with a dot as originating in the Internet Zone". It may be something else, but option (3) below should be a quick means of (dis)proving this as part of the problem.
The period (.) is not an oft-used character in a DNS hostname; it's usually interpreted as a separator between hostname and domainname (eg, localhost.localdomain). DNS hostnames are generally restricted to "LDH" -- Letters, Digits, and Hyphens.
UNC paths and Windows Networking (NetBIOS) names may suffer from similar problems. According to RFC3696, periods are legal, but you need to escape periods used within a hostname according to RFC1035. If I'm reading RFC1035 correctly, your hostname should be \.pfs instead of .pfs.
I'd wonder if your issues would work OK if you
changed the hostname (on the share server) to something not including a dot (and updated the client accordingly),
changed the UNC path to the share (on the client) to use the proper escape sequence for periods, or
changed the UNC path to the share (on the client) to use the IP address instead of the hostname.
This is the error that is thrown by our automated build suite on Windows 2008, while running ICEs (after migrating from WiX 2.0 to WiX 3.0):
LGHT0217: Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.". in light.exe(0, 0)
The FAQ is now deleted, however, the text from it said:
In WiX v3, Light automatically runs validation-- Windows Installer Internal Consistency Evaluators (ICEs) --after every successful build. Validation is a great way to catch common authoring errors that can lead to service problems, which is why it’s now run by default. Unfortunately, there’s a common issue that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to fail. For details on the cause and how to fix it, see Heath Stewart's Blog and Aaron Stebner's WebLog.
Additionally, these are the errors that show up in the event log:
MSIInstaller: Failed to connect to server. Error: 0x80070005
Product: [ProductName] -- Error 1719. The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.
Intuitively:
VBScript and JScript were registered under admin.
Integration service has permissions for the desktop interaction and all the files
Builds succeed, when executed manually on the same machine by another user or even user logged in as integration account (via RDP)
I'm out of ideas so far.
How do I solve this problem while keeping ICE validation?
End of the story:
After fiddling with the permissions of the integration account, DCOM, service activation, etc. without any luck, I finally simply disabled ICE validation in the continuous integration build, while still keeping it in the local build.
To disable ICE validation you can set SuppressValidation to true in the .wixproj file:
<PropertyGroup>
<SuppressValidation>true</SuppressValidation>
</PropertyGroup>
Or pass the -sval command line option to light.exe.
Adding the TFS build controller account to local admin group and restarting the windows service did the job for me.
I found the root cause. I tried everything I found, including custom validator extension similar to one posted in Re: [WiX-users] light.exe failed randomly when running ICEs..
It's not a concurrency issue as suggested in various threads. It's caused by a too large Process Environment Block (PEB).
It turns out Windows Installer can’t handle a process environment block larger than 32 kB. In my environment, due to number of variables set by the build system and their size (for example, PATH variable containing multiple duplicated values), PEB was about 34 kB.
Interestingly, per Environment Variables, Windows XP and 2003 had a hard limit of PEB set to 32 kilobytes. That would probably cause an easy-to-catch build break in an earlier phase of the build. Newer Windows' doesn’t have such limit, but I guess that Windows Installer developers limited their internal environment buffers to 32 kB and fail gracefully when the value is exceeded.
The problem can be easily reproduced:
Create a .bat file which sets environment variables which size exceeds 32 kB. For example, it can be 32 lines of set Variable<number>=<text longer than 1024 characters>
Launch cmd.exe
Execute the batch file you created
From the same cmd.exe window:
Try building the MSI package using WiX with ICE validation on OR
Run smoke.exe to validate your package OR
Simply run msiexec /i Package.msi
All the above commands will end up reporting Error 1719 - Windows Installer could not be accessed.
So, the solution is - review your build scripts and reduce number and size of environment variables so they all fit into 32 kB. You can easily verify the results by running:
set > environment.txt
The goal is to get file environment.txt smaller than ~30 kB.
The correct description (without a solution, except if adding the CruiseControl account into local administrators group can pass as a solution) of the problem:
Quote from Wix 3.5 & Cruise Control gives errorLGHT0217:
ICE validation needs an interactive account or administrator privileges to be
happy. See for example WiX Projects vs. TFS 2010 Team Build (2009-11-14) or Re: [WiX-users] Help with building patch (2009-11-20).
imagi is totally right! I could not believe this is the true answer. Supressing validation and making TFS user Administrator are not good solutions. Plus I could not find NT\Authority to add it to Administrators group and was totally stuck in this.
I got the same error on Windows Server 2012 Datacenter as Build Agent.
To solve the problem :
List item
Go to Environment Variables on the build agent machine
Create two System Variables
"PF86" which is equal to "C:\Program Files (x86)"
"PF" which is equal to "C:\Program Files"
They are so short because I want to save characters.I made them without the final backslash because TEMP, TMP and others were made so and I decided to stick to MS standard for these variables.
Edit PATH variable by substituting every "C:\Program Files (x86)" with %PF86% and every "C:\Program Files" with %PF%
Close and build and enjoy!
It worked for me. :)
UPDATE
I found a better solution : Rapid Environment Editor will do all this and even more for you. Automatically.
I faced the same problem and did not like to suppress ICE validation. My setup: I used my own computer as a build agent on Visual Studio Online (VSO). My solution was to change the account used to run the service on my machine. Instead of using Network Service or Local Service I simply made the service log on with my own account which had all the necessary rights.
From http://wix.sourceforge.net/faq.html#Error217:
In WiX v3, Light automatically runs validation--
Windows Installer Internal Consistency Evaluators (ICEs)
--after every successful build. Validation is a
great way to catch common authoring errors that can lead to service problems,
which is why it’s now run by default. Unfortunately, there’s a common issue
that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to
fail. For details on the cause and how to fix it, see
Heath Stewart's Blog
and
Aaron Stebner's WebLog.
I was getting same ICE error, but the problem turned to be corrupted Windows Installer Service.
This solution worked for me:
http://support.microsoft.com/kb/315353
Log on to your computer as an administrator.
Click Start, and then click Run.
In the Open box, type cmd, and then click OK.
At the command prompt, type msiexec.exe /unregister, and then press ENTER.
Type msiexec /regserver, and then press ENTER.
Restart Windows
Also, verify that the SYSTEM account has full control access permissions to the
HKEY_CLASSES_ROOT hive in the Windows registry. In some cases, you may also have to add Administrator accounts.
I have some suggestions.
Try updating the Microsoft Installer version on the build server
Make sure you use the newest release of WiX 3.0, since it's 3.0 release stable now.
If all else fails, try running the build service under a specific build user who you can fiddle with permissions for...
I got this error from my Azure build agent running on-premises.
My solution was to upgrade its user account from "Network Service" to "Local system account".
Go to your build machine and restart the Windows Installer service
None of the above suggestions worked for me, for me the anti-virus (mcafee) came into the picture and looks like it updated the vbscript.dll registry entry to a wrong DLL location. These are the things to keep in mind:
Some of the WiX ICE validations are implemented using VBSCRIPT.
So while compiling the MSI, the build server would need access to the c:\windows\system32\vbscript.dll.
Chances are that somehow the user that runs your build lost access to this DLL.
As mentioned in the above answers do look for the admin access/registry access and make sure your user has it.
Here are the steps that I took to fix the issue:
Open cmd (run as admin) on the build agent machine.
Run RegEdit
Select the root, then click ctrl + f and Search for the following registry entry : {B54F3741-5B07-11cf-A4B0-00AA004A55E8}
Look for the InprocServer32\Default Key
On my build agent, the path was replaced with a mcafee DLL location. I updated the path back to c:\windows\system32\vbscript.dll
Editing the registry entry was not easy, as it was a protected registry entry. I used the below link to get access permissions changed before I could edit the property: Edit protected registry entry
Once I updated the path, everything started working as usual.
My solution is similar to Vladimir's one. My CI user was admin of the computer.
But the following steps were mandatory to allow my jenkins build to succeed:
log in as CI user using rdp
open a dos command prompt
execute: %windir%\system32\msiexec.exe /unregister
execute: %windir%\system32\msiexec.exe /regserver
then i got a successfull job
The title says it. I'm looking for a way to determine exactly which file/registry key this executable is attempting to access. I have attempted to use Windows auditing capabilities and Process Monitor to determine where the failure is happening but, this failure does not produce audit failure events or show as access denial in Process Monitor.
Of course, If someone has experienced this and can provide a solution to resolve the error directly that would be almost as nice.
Background:
I am using moveuser.exe which is part of the Windows Server 2003 Resource Kit Tools to convert the security of local user profiles on a number Windows XP workstations.
Symptom:
Occasionally, moveuser.exe will fail to convert the security of a profile with the error "Error: 5 access denied". I have not been able to determine any commonality among the failing accounts or the computers they reside upon. A given computer may have host 6 profiles, 5 of which convert without issue and 1 which produces the error.
There are a few factors that I'm as sure as I can be about:
-The account I'm using to run moveuser.exe with has full Administrator rights to the local machine and the domain to which the profile security is being converted.
-The failure is not related to file permissions within the profile directory (the entire directory can be moved, renamed, deleted, or successfully converted via a workaround).
I've developed a reliable workaround for these cases but, it is fairly involved and I would much rather understand the root cause of this error and correct it pre-emptively.
My workaround (glad to share it, left out for brevity) seems to indicate that the failure is related to HKEY_LOCAL_MACHINE \ SOFTWARE\ Microsoft\ Windows NT \ CurrentVersion \ ProfileList registry keys but, I cannot determine exactly how/why.
Did you try to use the "regini" command line tool to grab registry permissions for the administrator account?
Use FileMon and RegMon (now Microsoft, formerly SysInternals, still free) to monitor what exactly is being accessed, how, and what rights/access are being requested.
I don't have a URL handy, but a Google search should be able to hook you up with these tools.
A couple items I would try. First, could it be that the user was logged in and the computer hasn't been rebooted. Microsoft has a product called UPHClent which helps in unloading unneeded user hives.
Next thing I wanted to know, is if you try rebooting before running the moveuser executable. This Conversation seems to indicate this would help with this kind of error.
Two days after posting this I got to the bottom of the problem. It turned out, just as Rob Haupt suggested to be related to a stuck user hive. The program I was running, moveuser, was reading the Refcount key found under HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows NT\ CurrentVersion\ ProfileList\ <SID>\ and ending immediately.
Setting Refcount to 0 solved the problem immediately
Pushing out UPHClean to all the target machines pre-emptively has all but elimated the problem and we were able to successfully convert profiles on several hundred machines over the last week.
An important note about UPHClean:
I'd tried installing it previously but, it didn't appear to help. I was too impatient, the UPHClean ReadMe revealed that the service just takes time to do its job.