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.

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.