when upgrading from 2.6.0.3 => 2.6.0.4 my grid node server install replaced the current user service was running under with "Local System" (choosing "Repair" with 2.6.0.4 seems to kept it though).
Daily Usage Issues
Remote server: Upgrading to 2.6.0.4 does not keep logon credentials for windows service
Started by GreenMoose on 6,756 views
Remco NCrunch Developer
#5572
20 Mar 2014 20:56 UTC
Thanks. This will be because an upgrade install is uninstalling the existing service, then installing the new one over the top. This is the cleanest way to ensure a full upgrade, as if the install parameters for the service ever change, the installer needs to be certain that the service is installed and registered correctly under the new version.
Ok but it's still a bug in installer, right?
Remco NCrunch Developer
#5577
21 Mar 2014 09:18 UTC
I think that would be a matter of perspective. I'll think you'll find that in many cases, upgrading a product of any kind where the installation state has been changed would probably give similar behaviour. For example, if you changed a .config file for a .NET product installed via MSI, you could reasonably expect that upgrading the product (and therefore installing a new set of files) would adjust to the changed file to a known state. The key point is differentiating between product configuration and install state.
Certainly, I agree that in your case this would be annoying as it is an extra step required for you when you install an upgrade. And for that reason, I can see the value in changing how this works.
Now, the situation I need to face is that the changes required to make the installer work in the way you are intending would increase the complexity of the grid node installation - such to the point where there would be an increased risk of failed installations or things going wrong. Failed installations are the bane of any developers existence, as installation success can be very environment specific and the edge cases are not always easy to test in advance. Thus a more complex install process introduces a greater risk of frustration for many users.
As such, I'd prefer not to change the service installation step for this installer unless there is evidence that a good number of people are impacted by needing to set the service to run as a local user. You're welcome to create a request for this on the uservoice page if you like.
Certainly, I agree that in your case this would be annoying as it is an extra step required for you when you install an upgrade. And for that reason, I can see the value in changing how this works.
Now, the situation I need to face is that the changes required to make the installer work in the way you are intending would increase the complexity of the grid node installation - such to the point where there would be an increased risk of failed installations or things going wrong. Failed installations are the bane of any developers existence, as installation success can be very environment specific and the edge cases are not always easy to test in advance. Thus a more complex install process introduces a greater risk of frustration for many users.
As such, I'd prefer not to change the service installation step for this installer unless there is evidence that a good number of people are impacted by needing to set the service to run as a local user. You're welcome to create a request for this on the uservoice page if you like.
Ok.
Edited 21 Mar 2014 10:24 UTC
Post a reply
Log in to reply.