I am creating a new app stack for an application that requires editing a service by adding a domain account under the logon tab of the service properties. My question here is whether the editing of the service should be done in the provisioning stage of the app stack creation? I have tested editing the service during the provisioning phase but when I enter the logon credentials and attempt to apply I get an "Access denied" error which I am thinking is due to my install machine not being a member of the domain. I am able to search for the domain and the specific account, however. Thanks in advance for any input you can provide.
install machine not being a member of the domain
Can you add it to the domain and check, app volumes needs to record the changes and you may be right as not being connected to the domain may be causing issues.
I openened a ticket with vmware to inquire about any adverse consequences to adding the install machine to the domain. If there is no foreseen issues with that I will give that a shot. Thank you for the quick response.
Its doesn't say it directly but the best practices VMware but mentions that that usually you want it to.
The provisioning virtual machine usually joins the same domain as the production virtual machine. However, this is dependent on the applications that are being provisioned. Some application requirements and licensing models require that the virtual machine shares a common SID with the production virtual machine.
I double-checked and the install machine is in the Domain. I also verified and the user account that I am login in with is a local account that does have "Service Log On" enabled. Machines in production have the very same rights but on those, I can ad the Log On account for the specific service. On the install machine, however, is where the "Access Denied" error comes up. It's the first time we've had to add a "Log On" account for a service so we are confused as to where this should be done, whether it has to be done while provisioning an appstack, or whether this would be a UEM capture. Either way, the install machine will error upon entering that Log On credential.
It's the first time we've had to add a "Log On" account for a service so we are confused as to where this should be done, whether it has to be done while provisioning an appstack, or whether this would be a UEM capture.
This question can be answered rather quickly. No you can't capture service changes using UEM/DEM. You can only capture user settings with DEM and services is a computer setting, no way to capture that.
And normally you should be abe to capture any changes to a service within the appstack. To be honest the way you are doing it should work so no idea why it is not working.
You could (but this is extrmeley cumbersome and I would not suggest doing this if you just started with Appvolumes) try to change the logon credentials after the package has been sequenced. You can update the appstack, assign it to a machine without an Appvolumes agent, add the snapvol.reg file from the appstack and change the service settings inthere but as said, that is extremely cumbersome and the question is if you can set the password because I guess it will be a hashed value ther that you would need to copy from somewhere else.
I appreciate your input. I will give your suggestion a try and see how it works out. VMware support answered my ticket but automatically defaults to suggesting contacting Microsoft or the app developer to ask their advice on how to virtualize this application. I think this should be something VMware should be able to advise on since all I am asking them is which route they would advise given that I need to capture this on log on account and I am sure Microsoft and the app developer will have no idea what I am talking about when I mention provisioning or capturing these sort of settings.
Can't you workaround it by configuring the service account to run via GPO "logon as a service" under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment?
Ensure that the user which you have added above is not listed in the ‘Deny log on as a service’ policy in the Local Security Policy.