We have developed a somewhat diffuse system for handling component installation and upgrades across server environments in an automated manner. It worked happily on our development environment, but I've run into a new problem I've not seen before when attempting to deploy it to a live environment.
The environment in question comprises ten servers, five each on two different geographical sites and domains. Each server runs a WCF based windows service that allows it to talk to each of the other servers and thus keep a track of what's installed where. To facilitate this process we make use of machine level environment variables - and modifying these obviously means registry changes.
Having got all this set up, my first attempts to use the system to install stuff seemed to work, but on one box in particular I'm getting "Requested registry access is not allowed" errors when the code tries to modify the environment variables. I've googled this, obviously, but there seem to be a variety of different causes and I'm really not sure which are the applicable ones. It doesn't help that this is a live environment and that our system has relatively limited internal logging capability.
The only clue I've got is that the guy who did the install on the development boxes wrote a very patch set of documentation on the process. This includes an instruction to modify the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy value in the registry and set it to 1. I skipped this during the installation as it looked like a rather dubious security risk. Reading the documentation about this key, it looks relevant but my initial attempts at installing stuff on other boxes without this setting enabled worked fine. Sadly the author went on extended leave over the holidays yesterday and he left no explanation of why this key was needed, so we're a bit in the dark.
Can anyone help us toward the light?
Cheers,
Matt
I've seen this error when code tries to write to the event log using something like EventLog.WriteEntry() and a source that is not a registered event source is specified. When a source is specified that has not previously been registered, it will attempt to register the source, which involves writing to the registry.
I would suggest taking a look at SysInternals Process Monitor:
http://technet.microsoft.com/en-us/sysinternals/bb896645
You can use this to monitor registry access and find out what key you're getting the access denied error on. This may give you some insight as to what is causing the problem.
Essentially he's disabling part of the Remote User Account Control. Without setting the value, Remote UAC strips administrative privileges from account tokens remotely accessing the machine. Yes, it does have security implications. See Description of User Account Control and remote restrictions in Windows Vista for an explanation.
Related
I'm trying to install bit vise ssh client but its not installing and throwing an exception as this.
Exception caught:
Failed to create directory "C:\Program Files(x86)\Common Files\Bitvise"
CreateDirectory() failed: windows error 5: Access is denied.
My system is 64 bit, I know bitvise has one version which supports both 64 and 32bit.
I also tried "run as Administrator", still same exception. Could anyone tell me the procedure to install it properly !
Logging: Always create an MSI log for debugging when encountering any deployment problems. See that link for hints on interpreting the log file content. Search for "value 3" first of all:
msiexec.exe /i C:\Path\Your.msi /L*vx! C:\Your.log
In general: check vendor web sites and / or user forums to figure out details on known issues. It could be a permission issue on your TEMP folder.
Emergency Approach: Use a clean virtual machine to get the software running. Try different OS-versions. Just for a heartbeat in a pinch. Or try someone else's computer. Obvious yes, but try it if you can.
Keep in mind that "very clean" virtuals (there is absolutely nothing on there - just a fresh OS) could lack certain runtimes that might be "taken for granted" and hence missing from an installer. VCRuntime, .NET versions and such. Just in case you see mysterious errors there too.
First Checks: A simplified, generic check-list for deployment issues:
AD / Group Policies: Corporate environments could have group policies and restrictions preventing the installation of anything at all. Check that first.
Installation Media: Re-download installation media to ensure its integrity.
Corrupted by Malware: Note that malware or other factors can corrupt downloaded files, but more commonly they are destroyed in-transit.
Wrong Bitness: The setup could be the wrong bitness (x64 on 32 bit system) or architecture such as Itanium (incompatible with normal x64 systems). Or even the wrong OS (zip file wrappers etc...).
Corrupted / Quarantined by Scanners: Security suites, firewalls, corporate blocks and the likes can cause problems (separate issue below - not sure if anti-virus programs try to clean binaries anymore? Block they certainly do).
Incomplete Download: Launching before download is fully finished (premature launch) is a classic weirdness - error messages are generally ok, but can be misleading. Remember to allow anti-virus scanners to complete their post-download scan. This can take much longer than you think (they hash the file, check their site, etc...).
Download Mirror Issue: Sometimes the download comes from a number of download servers, some of which could be corrupted or contain faulty media or be misconfigured. Download again - check with virustotal.com and repeat a few times to verify. Have your colleague in another office download? Different mirror likely (automatic load-balancing - when you can't pick another server yourself).
Network Problems (LAN): When you have problems, try to copy installation files to a local location (the desktop will do) to eliminate any LAN network issues as the source of your deployment problem. If there are network problems file copy might fail with a proper warning message? Network related fallacies. More towards bottom.
Missing Runtimes: A few, very core-runtimes can make setups fall over. This is particularly common on virtual machines that are "fresh" and basic.
Examples would be: VCRedist (in particular), .NET, Powershell, etc...
Lacking and more advanced components such as IIS, MSSQL, .NET Core, Java, etc... can also make some badly authored setups fall over.
Admin Rights: Ensure you have real admin rights on the box in question. In other words you are logged on using a real administrator account. Avoid "run-as" if you have a failure to look at. Try a real login.
Reboot: Just to try the obvious. Reboot and allow the PC to "settle down after reboot". This means you ensure that Windows Update hasn't started installing - or something else that was set to start pending the next reboot. PCs that are seldomly rebooted can have a lot going on after a reboot - some try to "reboot twice" - or even several times - to make sure all locks and blocks from "stuff that is happening" are released. Make sure to allow update operations to finish before rebooting once, twice or more (wait for reboot prompt). Virtual machines that are reverted to a previous state can be a nightmare when it comes to things that automatically start to update and cause confusion and problems.
Clean Slate: If you don't reboot, close down all applications before running your setup. This sorts out various locks and blocking happenstances. Preferably reboot first and run the setup the first thing you do when the machine is back up again. Again: give the machine enough time to be idle - everything started (services and such - and no updates installing).
Disk Space & Integrity: Ensure available free disk space AND that there are no errors on disk. The very small SSD and NVME disks of the last few years have made this problem more acute again.
Different user: Try installing as a different and real admin user. The important thing here is that this is a different admin account than you first tried (user account profile issues). So, in other words log in as a real admin user and don't just use "run as" (create a new account if you need to). An example of a problem could be someone who has messed up their user profile shell folder settings so that the directory table resolution of MSI fails. Another user profile would normally be unaffected and still work OK.
ACL - Access Control: Very often access denied can be related to custom NTFS ACL configuration that is erroneous. This can lead to weird error messages during installation. In corporate environments - with application packagers adapting installers - ACLs are sometimes modified extensively to tighten security. I have seen this a lot, but there are also other sources of ACL changes such as system administrator scripts, malware and I saw issues after a security fix from Windows Update a few years ago. Tightened security can trigger a lot of errors previously unseen in software that should "know better".
Malware check: Run anti-virus or Windows Defender to verify that you don't have a malware issue on your box. Additionally check the installation media with https://www.virustotal.com/ to ensure it is not malware itself! (the setup.exe could be infected, or the whole product could be malware outright - never know).
Security Software Interference: Anti-virus, firewalls, scanners and other security products can be overactive and block access to a folder or a resource so it looks like it is an ACL permission issue. Disable temporarily if possible when required. Do anti-virus software still try to fix binaries in the age of digital certificates? I am not sure. Always check installation file using virustotal.com.
Localized Setups: Sometimes setups made for other languages than English - or rather another language than the original setup (could be any language) - fail on systems with other languages installed and in use. Try on a clean virtual with the "setup-expected language". Problems like these indicate VERY bad setup design (hard coded localized paths, incorrect server paths or addresses due to translation errors, etc...) - but due to QA resources they are not uncommon. In essence the main-language version is generally (in almost all cases) put through better testing.
Mount Points: Some disks have mounted drives in folders and such things - this can cause some seriously weird problems. Try on a clean virtual with no drama-settings.
NTFS / FAT32: (Somewhat edge-case). It is no longer possible to install Windows 10 on a FAT32 drive - with the limitations that strike (no ACL permissions, max 4gb files, no journaling and such). However, the setup could be redirected to a non-system FAT32 partition or some other disk format. This could trigger security problems (no ACL permissions), but should not generally create any access denied issues - barring any custom actions trying to apply ACL permissions and failing (this might degrade gracefully by now, I don't know). However there are file size limitations in FAT32 disks (4gb) that might actually trigger errors these days for huge setups (games, video files, etc...). Note that downstream Windows OSs might still allow FAT32 system partitions. And finally - and importantly - FAT32 is not a journaling file system. This means data corruption can easily happen without self-correction.
Flagged Downloaded File: In newer versions of Windows downloaded files are flagged as "This file came from another computer and might be blocked to help protect this computer". See screenshot below. Read more details about the feature here and Digital signatures, false positives, tagged downloaded file. Just make sure your file does NOT have this flag (I do not have a complete overview of all problems that can result from this):
Odds and Ends: There are additional things such as setups being to old to install properly (they don't handle modern Windows features well - you can try to run the setup in compatibility mode by enabling this in the property page for the setup.exe file itself) and older Installshield setups had lots of DCOM-based installscript engine issues and such things. Other setup vendors have their own problems - and quite a few of them for older setups. Brand new stuff, and ancient stuff - always surprises.
Network Problems (LAN): This is mentioned above in the "Installation Media" section. You can copy files locally to try to eliminate LAN network problems as a source of problem (SAMBA problems, network overload and packet loss, interfering scanners, timeouts, etc...). You might get a real error message if you try to copy local. Try to download file directly from the Internet vendor site to the desktop as a test. Network related fallacies.
Update: Incompatibilities: It happens that software can't co-exist properly. These situations can be rather obvious (COM version incompatibilities, setups designed to detect existing software and prevent themselves from installing, setups in different language versions quarreling, etc...) or quite hard to work out (deep-seated driver problems, hardware peculiarities, anti-virus false positives or otherwise unsolvable problems). Make sure you test your setup on a clear virtual whenever you have problems. You can also use that as a "solution" if it works - have people run incompatible software on virtuals - obviously one of the key use cases for virtuals (there are many others).
Full Check List: See Section "Generic Tricks? in this answer for more.
Smartscreen issues: Digital signatures, false positives, tagged downloaded file
We are running a Nessus security scan. Unfortunately Particulars ServicePulse executable is coming up as a hit.
Path : c:\program files (x86)\particular software\servicepulse\servicepulse.host.exe
Used by services : Particular.ServicePulse
File write allowed for groups : Everyone
Full control of directory allowed for groups : Everyone
I thought it might be because of the service so I disable the service but it still comes up as a hit in the scan.
Is this software needed for NServiceBus if we are not using a dashboard to monitor?
It looks like the security scan does not like Everyone having full control. As long as the account the service is running under has Read and execute permissions it will work. By default ServicePulse is installed to run using the Local System account.
There is an issue open to address this https://github.com/Particular/ServicePulse/issues/514
ServicePulse dashboard gives an overview of your endpoints and failing messages.
If you are not using it to begin with, your endpoints will continue running, but you'll be flying blind as ServiceControl will be ingesting any failed messages and you won't see if there are any. If you use Heartbeat plugin or any other custom checks, that info will be not visible either.
There's an option of integrating with ServiceControl events, though I suggest you examine how your environment is set up in regards to ServiceControl, and don't disable ServicePulse without understanding the implications of disabling it and knowing your monitoring is covered.
The scan is complaining about file permissions that are too open. Everyone should not have write permissions in any Program Files folder.
I inspected my installation folder and have the same issue.
The fix is relatively easy:
Select the properties of folder C:\Program Files (x86)\Particular Software\ServicePulse
Select the Security tab
Select Advanced, a new dialog opens
Select Enable inheritance
Select OK and Yes on any confirmation dialog
Select Advanced again
Check Replace all child object permission entries with inheritable permissions entries from this object
Select OK and Yes on any confirmation dialog
Select Advanced again for the 3rd time
Remove the current entries where Inherited from states None, on my system those were Everyone and System, make sure that you see all other entries inherited from the parent folder and make sure you do not remove any of them.
Select OK and Yes on any confirmation dialog
It seems like hard procedure but that is because I'm being very detailed here. Some steps potentially can be combined but doing one change at a time keeps things easy to understand.
Now your file permissions are correctly set and comply to your security audit software.
I want my program to be able to edit a values within a registry key that resides in 'HKEY_LOCAL_MACHINE'
My.Computer.Registry.SetValue("HKEY_LOCAL_MACHINE\SOFTWARE\XYZ", "MyValue", "MyData")
The above works fine in Windows XP, but throws an UnauthorizedAccessException in Vista.
You are running into Vista's UAC feature. It will not let you write to arbitrary places in the HKLM hive because you are not running with Administrative priviledges.
There are two ways to work around this issue
Run the program with Administrative priviledges (different than running a program as an account which has Administrative priviledges)
Choose another place, perhaps HKCU, to store the data
The second option is much better as it allows your application to run with non-Admin priviledges which you can't always assume your user has.
Here is a fairly detailed article on UAC. It's not 100% programming material but it gives a good explanation as to what exactly it is and you can hopefully relate that to your particular program: http://technet.microsoft.com/en-us/library/cc709691.aspx
Since changes to the Local Machine hive can have affect across the system you will find that changes to it are restricted to non-administrative users. If you try to run your same code on an XP machine a non-admin account you will get the same error. On Vista since the process is non-admin by default you are getting this error. Information on this is in the "Made for Windows 2000", "Made for Windows XP", and "Made for Windows Vista" certification guidelines.
Given that I've got little information on what your program is doing more information may be needed to give you specific guidance, so I will speak in the general case. You want your application to leave the local machine hive alone unless you need it. When your program is run in non-admin mode it you can either disable the functionality that requires access to these admin keys or you can request that the admin privs.
Vista has tighter restrictions around Adminstrator accounts. If you're not logged in as an Administrator account, you'll have to write to HKEY_CURRENT_USER as opposed to HKEY_LOCAL_MACHINE.
IMO, this makes more sense. Each user has their own settings/etc for their programs. If you want to make global settings for your program, you'll have to do it with an Administrator account.
Where would you write an error log file, say ErrorLog.txt, in Windows? Keep in mind the path would need to be open to basic users for file write permissions.
I know the eventlog is a possible location for writing errors, but does it work for "user" level permissions?
EDIT: I am targeting Windows 2003, but I was posing the question in such a way as to have a "General Guideline" for where to write error logs.
As for the EventLog, I have had issues before in an ASP.NET application where I wanted to log to the Windows event log, but I had security issues causing me heartache. (I do not recall the issues I had, but remember having them.)
Have you considered logging the event viewer instead? If you want to write your own log, I suggest the users local app setting directory. Make a product directory under there. It's different on different version of Windows.
On Vista, you cannot put files like this under c:\program files. You will run into a lot of problems with it.
In .NET, you can find out this folder with this:
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
And the Event Log is fairly simple to use too:
http://msdn.microsoft.com/en-us/library/system.diagnostics.eventlog.aspx
Text files are great for a server application (you did say Windows 2003). You should have a separate log file for each server application, the location is really a matter of convention to agree with administrators. E.g. for ASP.NET apps I've often seen them placed on a separate disk from the application under a folder structure that mimics the virtual directory structure.
For client apps, one disadvantage of text files is that a user may start multiple copies of your application (unless you've taken specific steps to prevent this). So you have the problem of contention if multiple instances attempt to write to the same log file. For this reason I would always prefer the Windows Event Log for client apps. One caveat is that you need to be an administrator to create an event log - this can be done e.g. by the setup package.
If you do use a file, I'd suggest using the folder Environment.SpecialFolder.LocalApplicationData rather than SpecialFolder.ApplicationData as suggested by others. LocalApplicationData is on the local disk: you don't want network problems to stop you from logging when the user has a roaming profile. For a WinForms application, use Application.LocalUserAppDataPath.
In either case, I would use a configuration file to decide where to log, so that you can easily change it. E.g. if you use Log4Net or a similar framework, you can easily configure whether to log to a text file, event log, both or elsewhere (e.g. a database) without changing your app.
The standard location(s) are:
C:\Documents and Settings\All Users\Application Data\MyApp
or
C:\Documents and Settings\%Username%\Application Data\MyApp
(aka %UserProfile%\Application Data\MyApp) which would match your user level permission requirement. It also separates logs created by different users.
Using .NET runtime, these can be built as:
AppDir=
System.Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)
or
AppDir=
System.Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
followed by:
MyAppDir = IO.Path.Combine(AppDir,'MyApp')
(Which, hopefully, maps Vista profiles too).
Personally, I would suggest using the Windows event log, it's great. If you can't, then write the file to the ApplicationData directory or the ProgramData (Application Data for all users on Windows XP) directory.
The Windows event log is definitely the way to go for logging of errors. You're not limited to the "Application" log as it's possible to create a new log target (e.g. "My Application"). That may need to be done as part of setup as I'm not sure if it requires administrative privileges or not. There's a Microsoft example in C# at http://support.microsoft.com/kb/307024.
Windows 2008 also has Event Log Forwarding which can be quite handy with server applications.
I agree with Lou on this, but I prefer to set this up in a configuration file like Joe said. You can use
file value="${APPDATA}/Test/log-file.txt"
("Test" could be whatever you want, or removed entirely) in the configuration file, which causes the log file to be written to "/Documents and Settings/LoginUser/Application
Data/Test" on Windows XP and to "/Users/LoginUser/AppData/Roaming/Test on Windows Vista.
I am just adding this as I just spent way too much time figuring how to make this work on Windows Vista...
This works as-is with Windows applications. To use logging in web applications, I found Phil Haack's blog entry on this to be a great resource:
http://haacked.com/archive/2005/03/07/ConfiguringLog4NetForWebApplications.aspx
%TEMP% is always a good location for logs I find.
Going against the grain here - it depends on what you need to do. Sometimes you need to manipulate the results, so log.txt is the way to go. It's simple, mutable, and easy to search.
Take an example from Joel. Fogbugz will send a log / dump of error messages via http to their server. You could do the same and not have to worry about the user's access rights on their drive.
I personally don't like to use the Windows Event Log where I am right now because we do not have access to the production servers, so that would mean that we would need to request access every time we wanted to look at the errors. It is not a speedy process unfortunately, so your troubleshooting is completely haulted by waiting for someone else. I also don't like that they kind of get lost within the ones from other applications. Sure you can sort, but it's just a bit of a nucance scrolling down. What you use will end up being a combination of personal preference coupled along with limitations of the enviroment you are working in. (log file, event log, or database)
Put it in the directory of the application. The users will need access to the folder to run and execute the application, and you can check write access on application startup.
The event log is a pain to use for troubleshooting, but you should still post significant errors there.
EDIT - You should look into the MS Application Blocks for logging if you are using .NET. They really make life easy.
Jeez Karma-killers. Next time I won't even offer a suggestion when the poster puts up an incomplete post.
I work on quite a few DotNetNuke sites, and occasionally (I haven't figured out the common factor yet), when I use the Database Publishing Wizard from Microsoft to create scripts for the site I've created on my Dev server, after running the scripts at the host (usually GoDaddy.com), and uploading the site files, I get an error... I'm 99.9% sure that it's not file related, so not sure where to begin in the DB. Unfortunately with DotNetNuke you don't get the YSOD, but a generic error, with no real way to find the actual exception that has occured.
I'm just curious if anyone has had similar deployment issues using the Database Publishing Wizard, and if so, how they overcame them? I own the RedGate toolset, but some hosts like GoDaddy don't allow you to direct connect to their servers...
The Database Publishing Wizard's generated scripts usually need to be tweaked since it sometimes gets the order wrong of table/procedure creation when dealing with constraints. What I do is first backup the database, then run the script, and if I get an error, I move that query to the end of the script. Continue restoring the database and running the script until it works.
There are two areas that I would look at -
Are you running in the dbo schema and was your scripted database
using dbo?
Are you using an objectqualifier in either your dev or your
production environment? (look at your sqldataprovider configuration
settings)
You should be able to expose the underlying error message by setting the following in the web.config:
customErrors mode="Off"
Could you elaborate on "and uploading the site files"? New instance of DNN? updating an existing site? upgrading DNN version? If upgrade or update -- what files are you adding/overwriting?
Also, when using GoDaddy, can you check to verify that the web site's identity (network service or asp.net machine account depending on your IIS version) has sufficient permissions to the website's file system? It should have modify permissions and these may need to be reapplied if you are overwriting files.
IIS6 (XP, Server 2000, 2003) = ASP.Net Machine Account
IIS7 (Vista, Server 2008) = Network Service
Test your generated scripts on a new local database (using the free SQL Express product or the full meal deal). If it runs fine locally, then you can be confident that it will run elsewhere, all things being equal.
If it bombs when you run it locally, use the process of elimination and work your way through the script execution to find the offending code.
My hunch is that the order of scripts could be off. I think I've had that happen before with the database publishing wizard.
Just read your follow up. In every case that I've had your problem, it was always something to do with the connection string in web.config. Even after hours of staring at it, it was always a connection string issue in web.config. Get up, take a walk and then come back.
If you are getting one of DNN's error pages, there is a chance it may have logged the error to the eventlog table.
Depending on exactly what is happening and what DNN is showing you you might be able to manually look inside the EventLog table, pull out the XML data stored there, and parse it to find the stack trace and detailed information regarding the specific error at hand.
I have found however though that I get MUCH better overall experiences with deployments using backups and restores of my database, that way I am 100% sure that all objects moved correctly, and honestly it works better in my experience.
With GoDaddy I know another MAJOR common issue is incorrect file permissions, preventing DNN from modifying the web.config and other files that it needs to do.