I have a Windows 2012 Server running SharePoint 2010 using an SQL Server Express locally installed. Unfortunately my logs are currently flooding with message «An exception occurred while enqueueing a message in the target queue. Error: 15404, State: 19. Could not obtain information about Windows NT group/user ‘DOMAINuser’, error code 0x5.» It can be 20 such messages every second!
(…and the ‘DOMAINuser’ happens to be my personal account.)
Are there a job running that has missing rights? «Qoute from https://serverfault.com/questions/277551/mssqlserver-exception-occurred-while-enqueueing-a-message-in-the-target-queue-e «Try to changing the owner of the jobs to the sa account, on the properties of the job.» If I’m correct the express version of SQL server cannot run jobs? Or is there someone/something that wants access to our AD? Why do that account wants to obtain information about my account 20 times every second?
I do find lot’s of blogs and hints about this task, but I just dont understand the solutions. One says «To repair this, login as one of the SA accounts and grant SA access for the account that needs it.» But what account needs sa access?
asked Sep 15, 2014 at 10:22
Change the owner to sa. Here are the steps I took to solve this issue:
-
Right-Click on the database and select properties
-
Click on Files under the
Select a page -
Under the
Owner, but just below the Database Name on the right-hand pane, selectsaas the owner.
ΩmegaMan
28.3k10 gold badges98 silver badges116 bronze badges
answered Aug 21, 2017 at 10:09
olammyolammy
6,2984 gold badges25 silver badges32 bronze badges
6
In my case, sa was not the owner of the DB, I was. When I tried to execute CLR configuration that required sa privileges, I got the error too.
The solution:
USE MyDB
GO
ALTER DATABASE MyDB set TRUSTWORTHY ON;
GO
EXEC dbo.sp_changedbowner @loginame = N'sa', @map = false
GO
sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'clr enabled', 1;
GO
RECONFIGURE;
GO
I used help from the db team at work and this post to find the answer.
user
4,3135 gold badges17 silver badges34 bronze badges
answered Nov 17, 2014 at 21:46
Chaim EliyahChaim Eliyah
2,6534 gold badges24 silver badges37 bronze badges
7
In my case the owner of the database was a domain account DomainMe.
The error message was
Error: 15404, State: 19. Could not obtain information about Windows NT
group/user ‘DomainMyAccount’
The problem was that the database didn’t know what to do with the domain account — so the logical thing to do was to use a local account instead.
I tried changing the owner of the database, but things still wouldn’t work correctly.
In the end I dropped and recreated the entire database MAKING SURE THAT THE OWNER WAS SA
I also set the Broker to Enabled in the settings
Thing started magically working after this
answered May 6, 2015 at 11:38
2
No Domain Authentication
Failure was ultimately due to the fact that it was not able to authenticate when I was not vpn-ed into the corporate network.
For I was connecting to a local db on my work laptop, however the User ‘DOMAINuser’ needed to be authenticated by AD on the corporate network.
Error was resolved as soon as I reconnected and refreshed; the error disappeared.
ΩmegaMan
28.3k10 gold badges98 silver badges116 bronze badges
answered Jun 26, 2020 at 7:59
Ameet BhatAmeet Bhat
911 silver badge1 bronze badge
1
I had this error from a scheduled job in sql Server Agent, in my case, just after I changed the hostname of the Windows Server. I had also ran sp_dropserver and sp_addserver. My database was owned by «sa», not a Windows user.
I could login into SQL as the Windows user NEWHOSTNAMEusername (I guess after a hostname change, the SID doesn’t change, that’s why it worked automatically?).
However, in SQL, in Security/Logins node, I had SQL logins defined as OLDHOSTNAMEusername. I connected to SQL using «sa» instead of Windows Integrated, dropped the old logins, and create new ones with NEWHOSTNAMEusername.
The error disappeared.
answered Jan 11, 2016 at 14:26
Thierry_SThierry_S
1,48616 silver badges25 bronze badges
to do a bulk update for all databases, run this script and then execute its output:
SELECT 'ALTER AUTHORIZATION ON DATABASE::' + QUOTENAME(name) + ' TO [sa];'
from sys.databases
where name not in ('master', 'model', 'tempdb')
answered Mar 26, 2018 at 17:05
avs099avs099
10.8k6 gold badges57 silver badges109 bronze badges
I was having the same problem. In my case it was due to the fact that my machine was part of a domain, but I was not connected to the company VPN. The problem was solved after connecting to the VPN (so the domain user could be resolved by the SQLAgent).
answered Mar 1, 2021 at 13:41
erionpcerionpc
3271 silver badge14 bronze badges
I had the same issue where my domain login was not being recognized. All I did was go into the SQL Server configuration manager and start the services as Network Services instead of a local service. The sql server / agent was then able to recognize the AD logins for the jobs.
answered Jun 14, 2019 at 12:42
HaliHali
413 bronze badges
In my case, it was VPN issue. When I turned on the VPN to connect with my office network & then tried to start the snapshot agent again, it started successfully.
answered Oct 29, 2019 at 18:37
Ankush JainAnkush Jain
4,7964 gold badges29 silver badges51 bronze badges
2
I was facing the same issue.
Fix for me was changing the log-on from NT User to global user in Sql Server Configuration Manager => Sql Server Service => Sql Server Agent => Properties => Account name.
answered Apr 4, 2020 at 9:10
Jitan GuptaJitan Gupta
4447 silver badges15 bronze badges
You should be connected with your domain. (VPN)
answered Feb 8, 2022 at 8:53
WouterWouter
2,42219 silver badges30 bronze badges
Your SQL Linux has been joined to domain and you can connect to the SQL Server instance using Windows Authentication.
The connection itself is fine, but when you run some high privilege T-SQL statements like ‘Create Login’ , ‘sp_addsrvrolemember’ , you may run into the issue ‘Error 15404 ‘Could not obtain information about Windows NT group/user ‘%ls’, error code 0x80090304»
You will find following messages in PALLOG
11/22/2019 13:56:26.448761588 Debug [security.kerberos] <0000040947/0x00000200> Processing SSPI operation 0x0000000F
11/22/2019 13:56:26.449366379 Error [security.ldap] <0000040947/0x00000200> Initializing credentials for use in new cache failed: Keytab contains no suitable keys for red4$@SQLREPRO.EDU
11/22/2019 13:56:26.449613575 Debug [security.kerberos] <0000040947/0x00000200> Import name [ADMINISTRATOR@SQLREPRO.EDU] returned [ADMINISTRATOR@SQLREPRO.EDU]
11/22/2019 13:56:26.449633375 Debug [security.kerberos] <0000040947/0x00000200> Import name [red4$] returned [red4$]
11/22/2019 13:56:26.449753473 Debug [security.kerberos] <0000040947/0x00000200> Import name [RED4$] returned [RED4$]
11/22/2019 13:56:26.449905471 Debug [security.kerberos] <0000040947/0x00000200> Import name [red4$] returned [red4$]
11/22/2019 13:56:26.450014469 Error [security.kerberos] <0000040947/0x00000200> GSS MAJOR: 851968 GSS MINOR: 39756033 Error acquiring credentials in AcquireCredCaseInsensitive
11/22/2019 13:56:26.450029069 Error [security.kerberos] <0000040947/0x00000200> Unspecified GSS failure. Minor code may provide more information
11/22/2019 13:56:26.450039869 Error [security.kerberos] <0000040947/0x00000200> No key table entry found for red4$@SQLREPRO.EDU
11/22/2019 13:56:26.450053069 Debug [security.kerberos] <0000040947/0x00000200> SSPI operation 0x0000000F returned status: KerberosStream.cpp:2021 Operation unsuccessful
11/22/2019 13:56:26.450119868 Debug [security.kerberos.libos] <0000040961/0x0000020c> GetSecContextByUserABI() return value: 0x80090304
11/22/2019 13:56:26.488617991 Debug [security.kerberos.libos] <0000040961/0x0000020c> QueryContextAttributes() return value: 0x00000000
11/22/2019 13:56:26.488748289 Debug [security.kerberos.libos] <0000040961/0x0000020c> QueryContextAttributes() return value: 0x00000000
11/22/2019 13:56:26.489370580 Debug [security.kerberos.libos] <0000040961/0x0000020c> LookupAccountSid() return value: 0x00000001
Why?
When you run queries like ‘create login’, it will cause permissions to be checked. The first time you do it, it invalidates current permission. When you do it again, the permission check will be rechecked. When doing the permission check, SQL Server has to go through the mssql.keytab to pick up the machine entry key or MSA key. If SQL Server does not find the entries or find invalid entries, it raises error in question.
Here are three common scenarios that will cause the issue.
1.The machine account entries are not added. (mssql.keytab is configured by machine account)
If you skip the step ‘Option 1: Using UPN to configure the keytab’ in article https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-active-directory-authentication?view=sql…, you will run into this issue.
For example, here is a screenshot of valid mssql.keytab. If you don’t have the entries highlighted, error 15404 happens.
2.Credentials of the MSA are not added. (mssql.keytab is configured by Managed Service Account)
This is similar to the scenario 1.
For example, here is a screenshot of valid mssql.keytab. If you don’t have the entries highlighted, error 15404 happens
3.The machine account entries are expired. (mssql.keytab is configured by machine account)
To my knowledge, updating the machine account password cause the KVNO increase, and the machine account entries stall.
If someone in the SQL Server Linux runs following command: adcli update —computer-password-lifetime=0.
It will update the machine account password and caused the KNVO increase.
Please note, Windows domain controller does not control the machine account password update. It’s the client decision to update the password or not.
Even you have the ‘Domain member: Maximum machine account password age’ policy enabled, domain controller does not force clients to update machine account password.
Solution
===
1.For scenario 1 &2, just add then entries back.
2.For scenario 3, you need to recreate the mssql.keytab.
The ‘adcli update’ commands update machine account password, and refresh the /etc/krb5.keytab. You need to following the step ‘Option 1: Using UPN to configure the keytab’ , but with some changes.
The original steps is :
Now, you need to ‘Delete all the entries by their slot number that are not the UPN’, and delete all stalled UNP entries. Only UPN with latest KVNO are left.
For example, here is a screenshot of /etc/krb5.keytab.
You need delete all the entries, keep the entries highlighted.
- Remove From My Forums
-
Question
-
Hello, we running MSSQL Server 2008 R2 on Windows Server 2008 R2.
For MSSQLSERVER service we use special domain account (specified during installation of SQL Server).
Now we have some trouble with setting up replication, generally we have error: «Could not obtain information about Windows NT group/user ‘DOMAINuser’, error code 0x5», when try to start or delete replication instances or access other pagesfeatures.
For example, when I go to ‘Permissions’ page in Server Properties, and open ‘Effective’ tab in SQL Server Management Studio, I can see properties only for some domain accounts (that have Logins in MSSQL), for others I have error «Could not obtain information
about Windows NT group/user ‘DOMAINuser’, error code 0x5».I go to AD, try to view differents in those accounts, but at first glance it seems that they are identically.
Please help!
as is
-
Edited by
Friday, February 17, 2012 4:17 PM
-
Edited by
Answers
-
Marcin, thanks for suggestions, actually I fixed this by myself )
All I need, is grant ‘Read’ permissions to Auth Users for users.
Thanks for helping!
as is
-
Marked as answer by
Arthur_LiMicrosoft contingent staff
Monday, February 20, 2012 7:58 AM
-
Marked as answer by
== I asked this question directly to Remus and wanted to share the response to all of those people using this forum ==
We recently moved our database server from SQL Server 2000 to SQL Server 2005. All applications on our intranet development server stay the same [VS.NET 2003], but recently resources in our Dev DB server ran out of space. While doing a thorough investigation, I noticed ERRORLOG file was occupying about 35 Gig of HDD space. I immediately checked SQL Server error log and noticed an entry which says –
===========================================================================================
Date 7/7/2006 4:45:37 PM
Log SQL Server (Current — 7/7/2006 4:45:00 PM)
Source spid77s
Message
The activated proc [dbo].[SqlQueryNotificationStoredProcedure-5eaf8465-d0cb-4be7-93b6-44bb979dd41c] running on queue BW_Content.dbo.SqlQueryNotificationService-5eaf8465-d0cb-4be7-93b6-44bb979dd41c output the following: ‘Could not obtain information about Windows NT group/user ‘BWCINCHoffK’, error code 0x534.’
===========================================================================================
What is this SqlQueryNotificationService in my database? Is it a SQL Server 2005 thing? Why the same kind of stored procedure does not exist in other databases, but BW_Content? This error is getting repeated most probably every second and is filling up our server.
I believe our corporate IT people removed our domain accounts from BWCINC domain to BWCORP domain and probably some application which is using BWCINCHoffK credential is getting errored out. I tried to locate this application and was not successful.
Is there anyway that I can stop this ERRORLOG from growing? How can I delete these log entries so that I can make space on our Hard Drive? Is there an easy way in SQL Server 2005 to locate which application is creating this error?
Response from Remus:
The ‘SqlQueryNotificationService-…’ is the service created by SqlDependency when you call SqlDependency.Start (). The problem you describe appears because the ‘dbo’ user of the database is mapped to the login that originally created this database. The SqlDependency created queue has an EXECUTE AS OWNER clause, owner is ‘dbo’ and therefore this is equivalent to an EXECUTE AS USER = ‘dbo’. The error you see is reported by the domain controller when asked to give information about the original account ‘dbo’ mapps to (that is, BWCINCHoffK’): Error code: (Win32) 0x534 (1332) — No mapping between account names and security IDs was done.
To find the databases that have this problem, run this query:
select name, suser_sname(owner_sid) from sys.databases
The databses that have the problem will show NULL on the second column.
To remove the entries, use sp_cycle_errorlog to force a new errorlog file, then delete the huge log file.
—————————————
I got this error in SQL Error Log once and the growth of ERRORLOG was stopped.
===============================================================
Date 7/10/2006 1:16:55 PM
Log SQL Server (Current — 7/10/2006 1:17:00 PM)
Source spid20s
Message
The query notification dialog on conversation handle ‘{6BDE95F7-0EFB-DA11-9064-000C2921B41B}.’ closed due to the following error: ‘<?xml version=»1.0″?><Error xmlns=»http://schemas.microsoft.com/SQL/ServiceBroker/Error»><Code>-8490</Code><Description>Cannot find the remote service 'SqlQueryNotificationService-c15bb868-ed56-47d2-bf91-ce18b320989a' because it does not exist.</Description></Error>’.
===============================================================
Should I be concerned about this error?
Thanks
-Binoy
May 6, 2020 by Kenneth Fisher
This is an interesting error that you’ll occasionally get when accessing an AD/Windows ID.
Msg 15404, Level 16, State 11, Line 6
Could not obtain information about Windows NT group/user ‘SQL2019TESTENVDopey’, error code 0x534.
Pretty simple reason here. The AD/Windows group/user no longer exists (or is inaccessible) but the entry for it exists inside of SQL.
Now what do I mean by “accessing”? Well the easiest way to get the error is to try to impersonate the id.
EXECUTE AS LOGIN = 'SQL2019TESTENVDopey'; EXECUTE AS USER = 'SQL2019TESTENVDopey';
I’ve most frequently seen this happen when someone has left the company (or a service account is removed for whatever reason) and the corresponding SQL principals (logins & users) have not been removed.
When this can get really interesting when you go to look up the name in AD/Windows and it’s still there!?! Basically what’s happened is that the SID has changed at the AD/Windows level. I believe this can happen when removing/re-adding an id but when I tested in Windows dropping and re-creating the Id gave me the same SID. I could be missing something though. Regardless the SID in SQL no longer has a match in AD/Windows.
Now that we have the error what do we use to fix it? Well, if the Id is gone and is supposed to be gone drop your associated logins and users. If on the other hand the Id still exists but the SID doesn’t match anymore it’s a bit more complicated.
First script the login (server principal) and all of it’s server level role memberships and permissions then drop and re-create it. Generally I use my sp_SrvPermissions stored procedure for this. You do not have drop any users (database principals). You will have to do the following in each of the databases were a related user exists.
ALTER USER Dopey WITH LOGIN = 'Dopey'
This will change the SID of the user to match the login.
To the best of my knowledge this can also happen with Azure SQL databases and AAD although I haven’t tested it yet.
Category: Microsoft SQL Server, Security, SQLServerPedia Syndication
| Tags: Microsoft SQL Server, security
This is one of those typical blog posts that I write for my future self, the guy who keeps fixing the same stuff over and over and forgets what he did the next minute.
If you want to query information about a Windows user or group and its access path in SQLServer, you can use the extended stored procedure “xp_logininfo”. Here’s an example:
EXEC xp_logininfo 'MyDomainSomeUser','all';
If everything is configured correctly, you will see a list of Windows accounts and the login(s) they are mapped to in SQLServer.
However, in some cases, the command fails with the infamous error message:
Could not obtain information about Windows NT group/user 'MyDomainSomeUser', error code 0x5This happens every time SQLServer tries to query information about the Windows user from Active Directory and receives an error.
Understanding where the error comes from can be tricky, but it can become easier to troubleshoot when you understand what happens behind the scenes and what are the most likely causes.
The user does not exist
This is very easy to check: does the user exist in Windows? Did you misspell the name?
You can check this from a cmd window, issuing this command:
net user SomeUser /domain
If you spelled the user correctly, the command will return information about it, like description, password settings, group membership and so on.
If the user name is incorrect and cannot be found in AD, you will get an error message
The user name cannot be found.
Easy peasy: check your spelling and check your AD.
The service account does not have enough privileges to query AD
As I said, SQL Server needs to query AD to retrieve information about the user: if its service account doesn’t have enough privileges, the query will fail.
The most likely cause for this is a misconfiguration of the service account settings in SQL Server. To be more specific, it is very likely that SQL Server is configured to run as a local user who has no access to Active Directory at all. This happens when SQL Server runs as a per-service SID or one of the built-in local accounts (local service or localsystem).
It is very easy to check what account is being used to run SQL Server: all you need to do is query sys.dm_server_services.
SELECT servicename, service_account FROM sys.dm_server_services;
If you see a local account being returned, go ahead and change your service account to a domain account, using the Configuration Manager.
If you still can’t query AD, maybe there is something wrong with the permissions on your AD objects. Try impersonating the SQL Server service account, open a cmd windows and issue the net user command.
> net user SomeUser /domain
The request will be processed at a domain controller for domain MyDomain
System error 5 has occurred.
Access is deniedIf you get the “Access is denied” error message, you need to go to your AD and grant read permissions on that user/OU to the service account.
The service account does not have enough privileges to impersonate the windows user
This was a bit of a surprise for me. In order to retrieve information about the Windows user, SQL Server needs to impersonate it first and then will contact AD impersonating that user.
In order to impersonate a user, SQL Server needs to run under a service account user that has enough privileges to impersonate another user. This privilege is granted through a local policy.
Open the local security policy MMC (secpol.msc) and expand “Local Policies”, “User Rights Assignment”. Find the policy named “Impersonate a client after authentication” and double click it. You can verify whether the service account for SQL Server is granted this privilege, directly or through one of its groups.
Generally speaking, you don’t have to change this, because by default Windows grants this privilege to the “SERVICE” special identity. Any process running as a service is acting as the SERVICE special identity, including SQL Server. If you don’t find it listed here, add it back.
Windows permissions can get tricky at times. I hope that this post helps you (and me!) taming the beast.
Have you ever changed Server name on which SQL Server instance is installed? One of my friends changed the hostname of a Windows server with SQL Server already installed. After this, the SQL Server maintenance plan jobs started to fail. As we know, internally SQL Server still shows the old hostname this must be dropped manually. Otherwise your SQL Server maintenance plan jobs fail with this error.
The Job failed: Could not obtain information about Windows NT group/user 'XXXXXXAdministrator', error code 0x534. [SQLSTATE 42000] (Error 15404))
In this post, I will show you the procedure to resolve the errors and execute the SQL Server Agent Maintenance Plan jobs successfully. Below is the error screenshot showing job failure in the SQL Server agent logs. The error is highlighted in the image in red.
First, connect to your SQL Server instance with SQL Server Management Studio and run the below queries to check SQL Server name:
use master
select @@SERVERNAME -- The current hostname SQL Server recorded
select SERVERPROPERTY('machinename') -- The hostname the operating system recorded
In the below screenshot, the server name and machine name are different.
Run the below shown T-SQL scripts to drop the old server name, and then it add back the SERVERNAME to match the operating system’s hostname.
In the below screenshot, first we dropped old server name.
In the below screenshot, we have added new server name using T-SQL.
Now, log into the SQL Server with a “sysadmin” privileged user. Go to SQL Server logins, and you can still see the oldServernameadministrator login bound with the SQL Server engine.
Drop the login “OldServernameadministrator” and create a new windows login as “NewServernameadministrator”, adding the sysadmin Server role.
CREATE LOGIN [NewServernameadministrator] FROM WINDOWS; GO EXEC sp_addsrvrolemember N'NewServernameadministrator', N'sysadmin';
In the below screenshot, we have added “DB01administrator” login.
The owner of the job associated with maintenance plan is OldServernameadministrator. We need to reset the ownerid using the below T-SQL Update query.
Now, We need to reset the owner of the job associated with the maintenance plan by running the below T-SQL query. In below screenshot, reset the owner of the job.
Right click on SQL Server job and select properties and change the owner of job to “sa” login.
Delete old maintenance plan and re-create the maintenance plan. Right click and click execute maintenance plan. You can see maintenance plan executed successfully. J
Regards,
Ganapathi varma
Senior SQL Engineer, MCP
Email: Gana20m@gmail.com
SQL Server Agent 15404 Error
If you encounter in the Sql Server Agent Log «SQLServer Error: 15404, Could not obtain information about Windows NT group/user ‘ISTMRKSQLHOSTAdministrator’, error code 0x534. [SQLSTATE 42000] (ConnIsLoginSysAdmin)» this is related with Sql Server Agent job security.
Open Sql Server Management Studio, go to Object Explorer select Jobs under SQL Server Agent. Find your Maintenance Plan and right click on it, select Properties. On the General Page change Owner to ‘sa‘. Then execute the maintenance plan again.
Popular posts from this blog
On HP 3PAR Storage, disks are grouped inside magazines. So when it comes to replacing a failed disk, magazine that holds the disk has to be brought offline using a servicemag start command.
In this post, I am going to explain configuring multiple VLANs on a bond interface. First and foremost, I would like to describe the environment and give details of the infrastructure. The server has 4 Ethernet links to a layer 3 switch with names: enp3s0f0, enp3s0f1, enp4s0f0, enp4s0f1 There are two bond interfaces both configured as active-backup bond0, bond1 enp4s0f0 and enp4s0f1 interfaces are bonded as bond0. Bond0 is for making ssh connections and management only so corresponding switch ports are not configured in trunk mode. enp3s0f0 and enp3s0f1 interfaces are bonded as bond1. Bond1 is for data and corresponding switch ports are configured in trunk mode. Bond0 is the default gateway for the server and has IP address 10.1.10.11 Bond1 has three subinterfaces with VLAN 4, 36, 41. IP addresses are 10.1.3.11, 10.1.35.11, 10.1.40.11 respectively. Proper communication with other servers on the network we should use routing tables. There are three
Recently I have to export the user list for a particular domain. Luckily Zimbra has Admin GUI with a search feature. When you search accounts, you can download search results as a comma-separated csv file. So I did a search and download the result file, but the result did not have all the columns I need and also there is no option for customizing columns for search results. So I had to write a bash script to get the desired list. Here is the bash script ( It can be customized by adding or removing field names. Run it under zimbra user like ./zimbra_account_list.sh <domain_name_here> ):
I’m going slightly nuts. I’m a programmer by trade — and I only dabble in NT security and DB setup issues.
However, we had a server fail to reboot after a MS Update. I’ve restored the entire machine from Windows Backup — but I’ve realized that I cannot rebuild the machine because one cannot realistically use a Windows Backup to restore a database to a different machine, AFAICT. Rather, I need actual DB backups to do that.
In pursuit of having regular SQL Server backups, I’m running into the title error:
[298] SQLServer Error: 15404, Could not obtain information about Windows NT group/user ‘WIN-443PT0LULQUAdministrator’, error code 0x534
Essentially, I’ve enabled SQL Server Agent viz SSMS, then I created a management plan to do full backups on our SQL server instance, and scheduled it for daily operations.
However, when I manually ask it to execute that job — to ensure all is working correctly — I get the error:
[298] SQLServer Error: 15404, Could not obtain information about Windows NT group/user 'WIN-443PT0LULQUAdministrator', error code 0x534
That sounds to me like an NT permissions issue — that whatever it is — XP Agent? — attempts to retrieve the permissions of the aforementioned user — and that fails.
Part of what is bizarre here — is there is not machine ‘WIN-443PT0LULQU’ — that doesn’t exist — WTH is SQL Server forcing that in there for in the first place?!
I want this to run as the Administrator — on the local machine ‘BUILD-SERVER’ — not that garbage name it keeps forcing…
I’m way out of my depth here and this whole process is crazy-making.
How in 2018 is it not possibly to click a few wizard NEXT style buttons and configure Windows / SQL Server to back its freakin’ self up regularly correctly?
WRITE FOR US