0

We have developed a backup software for a SQL Server(2019) that runs on a Windows Server 2019 for a customer.
The app (.net Windows Forms) has an interface to configure the backups (e.g. select day's for backup, backup times every day, and so on) and further configuration's (data to SMTP-Server, mail distribution list, and so on). Further the client contains functions to restore database. The backups are started over a timer.
The App works fine, but has to run 24/7/365.
Problem description:
The app run's on a customer server and the customer don't allow accounts where the password never expire.
Further the server is (at least) rebooted every two weeks automatically. So... we have to access the server and start our client new at least every two weeks, what is not nice.
Therefore, we think about to "split" the backup App in two parts:

  • Windows Client (with deactivated backup and E-Mail functions)
  • Windows service (read the config files at startup, do the backups, send E-Mails)

=> Target: The Service to the backup is started automatically after a server reboot (no need to start in manually).
Needs:
The Service need to have access to the local disk (read (.ini) configuration file, store the backups), to the SQL-Server (installed on the same server) and to the SMTP-Server (located on another customer server) to be able to send E-Mails.
As mentioned above, the target is to use a "system account" without password (that has to be changed periodically).
We are developers, not system engineers... therefore the "starter questions":
As far as we know, there are System accounts for "Local System", "Local Service" and "Network Service" (maybe there are more...).
Question:
Has one of the above mentioned accounts all needed rights (or is there another)?

Thanks!

FredyWenger
  • 103
  • 2

1 Answers1

1

Yes, you absolutely need to have the interactive "configuration" and "service" parts separate. The Service part needs to run all the time, the configuration part only as and when needed.

The idea of having an application running "on the console" of a Windows Server these days is troublesome, at best, and gets harder with each version of Windows. Having produced Windows Services that are still in Production 20 years on, I'm a little surprised you didn't come across this "challenge" during development and testing.

But anyway ...

The app run's on a customer server and the customer don't allow accounts where the password never expire.

Given that Windows supports numerous, "system" accounts whose password never expire, this is a strange "Requirement" to have inflicted on your application.

Question: Is this "Requirement" actually relevant?
To use the "configuration" app, you would need to log into the machine, so you'd use whatever credentials you were given for this purpose - those, interactive, User-specific, credentials should expire periodically.

The "service" part should just run and do stuff.
If these system accounts had expiring passwords, the Windows ecosystem would be utterly unusable.

The Service need to have access to the local disk (read (.ini) configuration file, store the backups) ...

Yes, absolutely.
Any of the "Service" accounts should have this level of access.

... and to the SMTP-Server ... to be able to send E-Mails.

Access to anything "off" the box requires a Network-aware account.
Network Service is probably your best bet.

... to the SQL-Server (installed on the same server) ...

Danger, Will Robinson!
Are you seriously saying that your "backup" utility is taking and storing SQL Server backups on the same machine as the SQL Server instance itself?

This undermines your whole solution.

If you lost the machine on which SQL Server was running, then you'd also lose the backups of your database as well and, since the only reason that backups exist is to guarantee that you can get the database back no matter what goes horribly, horribly wrong, then your "backup solution" is completely compromised.
You absolutely must get the backups off of that server and onto a.n.other machine, well away from the databases that they are protecting.

Phill W.
  • 1,479
  • 7
  • 7
  • Thanks for your reply. So.. I think, I should go with the Network Service. Regarding the backups on the same machine: You're principally right, but the server is a VIRTUAL server that is backed up every hour from the IT of the customer. So... we already would have a backup (of the whole server), but the IT of the customer mandatory wanted a logical backup in advance. So the backup of the backups is guaranteed. – FredyWenger Feb 07 '22 at 15:49
  • Database != File. A backup of the server is only good as of the Point in Time it was taken. SQL Server backups allow /far finer/ granularity of Recovery. And just because something is a VM Guest DOES NOT make it safe from the *VM Controller* deciding, one day, to randomly "scribble" all over its disks - the same disks that hold the disk images of the running, VM Guest machines, utterly trashing them in the process! Been there. Seen it. Not pretty. I would suggest that your Recovery Strategy needs a bit of "fine tuning". – Phill W. Feb 07 '22 at 16:14
  • I have successfully developed the windows service now and start it under the network service. Anything works, but I had to grant the network service in addition some rights in the file system. I have accepted your answer now. Thanks again. – FredyWenger Feb 17 '22 at 18:48