Hello
I've been at war with WSUS, getting it to install on a 2012 R2 member server in a 2008 domain.
The first stage of the role installation was fine, but the post installation tasks failed. First of all the security on the ..\webservices folders was not set correctly but I found a solution to that where iCACLS was used to grant permissions. Next, the NT SERVICE\MSSQL$MICROSOFT##WID account could not be used to start the WID service because it did not have the Log on as a service right.
It's this last bit that I'm having continuing problems with. I ended up using services.msc to change the WID logon to use the local system account which worked fine and the post installation tasks completed successfully.
>>Note that WSUS is now up and running - updates are being downloaded and clients are reporting to the server.<<
However, when using Group Policy to grant the NT SERVICE\MSSQL$MICROSOFT##WID account the log on as a service right in User Rights Assignment I am unable to get the account recognised. I have tried using the full form NT SERVICE\MSSQL$MICROSOFT##WID and just the account itself and then using Check names to validate it, but it fails to validate.
I left the account name in the Log on as a service settings and rebooted the WSUS server in the hope that the service would be properly installed and registered on the system. Since then,as mentioned above, I abandoned the use of the account to start WID and chose the option to use the Local system account because NT SERVICE\MSSQL$MICROSOFT##WID has never been recognised. I also saw many SceCli 1202 events in the Application event logs stating an account cannot be resolved to a SID. Running the Find command against winlogon.log, MSSQL$MICROSOFT##WID is the culprit. I have now removed the account from the Group Policy setting.
My question is: can I leave the system account 'in charge' of WID? It seems clear that NT SERVICE\MSSQL$MICROSOFT##WID does not exist and is not affecting the performance of the WSUS installation.
Many thanks
Mark