And on the UAC and XPP installer really getting Administrator permissions discussion, I'll just add that we are investigating whether there's something "missing" in the XPP installer as to it checking/asking for (and getting) real Administrator permissions for the install.

The install code does have check/abort code that's supposedly checking for Administrator permissions and aborting with a message if that permission is lacking.

However, we're reading on the web a lot of stuff that seems to indicate that this "check" seems to no longer be working - seemingly since the introduction of UAC and/or the newest versions of Windows.

It's being worked on as we speak (for the future XPP 9.5 installer) ...

I like the idea of a XPP "temp" folder. Historically, a number of years ago we used to write to %TEMP% which was set to "...AppData/Local/Temp" but that became a problem on XPP servers, because the "temp" folder was not accessible to all users; just the one that did the install. So we changed it to the windows "temp" folder. However, in later Windows server releases MS started delivering the file as read-only for regular users.

My recommendation would be to create it at the top level with "xz" and 'sd_liz". So there would be one more folder there called "temp" and XYV_TMPS would be set to this automatically on an install. This would eliminate the need for XPP to deal with the write permissions to "WINDOWS\TEMP".  I think upgrades should probably just leave the XYV_TMP alone, although I could be convinced to change it all the time. However, that would cause re-installs to put the value back if a user went and changed the value after the install/upgrade. Thoughts?

As for item #2, I am not in favor of adding this check to the installer. We have been burned by this before. In previous installers, two years down the line a customer wanted to install XPP on another server but a system check failed because MS in in its infinite wisdom made changes under the hood. So now a valid install image is "broke". I do not want to be in the business of chasing MS changes with re-issues of installers for old releases

However, I would be in favor of a possible Powershell script as a companion to the install that checks for missing components. This would not prevent the installer from running, but provide a nice way to check for certain files that need to be there for certain functions in XPP to run properly. If something changes, CS can provice an updated PS script. Its just a thought.

I should talk about UAC since it was mentioned in the idea. I will recommend that we change the doc about UAC. MS recommends that it always be on, but the documentation is a little ambiguous and sort of implies that you need it turned off for XPP to install. This is not the case. With it on, you just get a warning message when an administrator loads XPP. XPP should load fine after saying "yes". The problem is when you turn it off via the control panel you are just disabling the warning and the program runs as a non-administrator. This is why the doc goes on to talk about looking online on how to really turn it off. We do not document this process because MS can change this yet again, and we do not want to be chasing MS doc with XPP doc. In this scenario, administration rrights is used for installing the 'bgguer' and 'sproc' services (if selected to be installed) and the "install services" command will fail due to lack of privileges. However, due to a bug, the current product installers do not warn the user that the services failed. Since we cannot re-do the older installers (i.e. 9.4), this will be addressed in the 9.5 installer.

The end-user issue that I've run into that prompted the request above was that the AutoProc and BGQuer services didn't get installed properly (prompting a support ticket - case 00266074).

If the UAC check cannot be done before/on install, is there a useful error message that can be thrown after install?

I'll just add that as far as "verifying" that the three UAC settings are set properly, this is probably not something we would add to the installer.

Turning off UAC (completely) is only a recommendation for doing an XPP install; it's not a requirement. AFAIK as long as you run the XPP installer properly when UAC is (completely) enabled (e.g. always use 'Run as administrator' even if logged in as an administrator), it's not necessary to disable UAC.

It's Microsoft that has made disabling UAC such a "stupid" multi-step process, and that's why we went through the trouble to document that in detail for those who do want to (completely) disable UAC.

Real install problems arise when UAC is only partly disabled (usually by those who remember when disabling UAC was only a one-step process), in which case Windows silently does not run the installer with administrator permissions even if the user is logged in with an account that has been give administrator permissions.

Jonathan Dagresta
RWS XPP Engineering

Thomas,

But a bigger chance that you get at least 1 of the 2 points raised... :-)