Backup on shared folders running on a local system account?

I still see a lot of SQL Servers running using the LocalSystem account, particularly, MSDE 2000, which is very popular among third-party applications that requires storing data in a database. Others run a stand-alone SQL Server system and use LocalSystem account for the service accounts. While this may be a security risk, a lot of users still have them configured. And when they need to generate database backups on a shared folder, the SQL Server service's attempt to connect to network resources are denied access because they have no credentials and they are using a null session.Of course, a typical recommendation would be to change the service account to a local Windows or a domain account with least privilege but not everybody is open to that suggestion. So how do you allow SQL Server to generate a backup on a shared folder while using a LocalSystem account? The solution: enable null session shares

While I do not advocate such workarounds as it opens up additional security loopholes, it still is a workaround. And as I usuallly say, WARNING: This is not a recommended approach. Use at your own risk

Microsoft has a documented procedure to enable null sessions shares and while the KB article mentions Windows 2000, it does work for Windows Server 2003. This should be done on the Windows machine that hosts the shared folder. A word of caution if you intend to use this approach - document every step that you do and make sure you rollback any changes made after generating your database backup. Tasks like enabling the Guest user account (this is disabled by default), modifying the registry, etc. should be rolled back as soon as you're done, otherwise, you're opening up security vulnerabilities across your network.

Can't run your batch files from Scheduled Tasks? Try this

I was asked by a friend of mine to check why a specific batch file was not being called by a job in Task Scheduler. The first thing I did was to check if the account that was used to run the job had the appropriate permissions. The account used was a domain account with limited privileges. The same account can run jobs on other servers but not on this one. Making it a member of the local Administrators group gave it the permissions to run the job but not as a member of the Power Users group. The former not being an option forced me to check the ACLs on other servers and found out that the account does not have permissions on the CMD.EXE file on my %windir%\system32 folder. After giving the Read and Execute permissions to this account, it was able to run the job using Task Scheduler.

I've seen systems where the Everyone group is granted the same permissions on the CMD.EXE file and such is not a recommended practice due to security vulnerabilities. I'll work on a PowerShell script to check a machine for this and remove the Everyone group, if it exists.