{"id":1813,"date":"2014-05-28T00:00:00","date_gmt":"2014-05-28T00:00:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/setting-up-your-sql-server-agent-correctly\/"},"modified":"2021-08-24T13:39:44","modified_gmt":"2021-08-24T13:39:44","slug":"setting-up-your-sql-server-agent-correctly","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/databases\/sql-server\/database-administration-sql-server\/setting-up-your-sql-server-agent-correctly\/","title":{"rendered":"Setting Up Your SQL Server Agent Correctly"},"content":{"rendered":"<div class=\"article-content\">\n<p> \tSQL Server Agent is a job scheduling agent that ships with SQL Server. Its infrastructure consists of a Windows service that is used to execute tasks (called <em>jobs<\/em> in SQL Server parlance), and a set of SQL Server tables that house the metadata about these jobs. The agent can execute numerous types of jobs, either on a schedule, or on-demand. In this article, we will look at some of the best practices for security that should be followed when installing and setting up SQL Server Agent. I&#8217;m assuming you already have a working knowledge of configuring and using SQL Server Agent. <\/p>\n<h2>Who sees what<\/h2>\n<p> \tA common request that DBAs get is to grant the development team access to SQL Server Agent. As with all database access, you should grant only as much access as required, because of the inherent security risks of a task scheduler. <\/p>\n<p> \tSQL Server contains 3 fixed database roles on the MSDB database, which gives administrators fine control over access to SQL Server Agent. The SQL Server Agent node in SSMS is visible only to users in one of these 3 roles (except sysadmins, who can see everything irrespective of role membership). Here is an explanation of the roles, in order from the most restrictive to least restrictive: <\/p>\n<ul>\n<li><strong>SQLAgentUserRole<\/strong> &#8211; Users in this role are granted view\/edit\/delete\/execute access to only jobs owned by them. Users in this role cannot view any jobs owned by system administrators, or by users in the other two roles. <em>Grant this role when you want users to only see jobs owned by them<\/em>.<\/li>\n<li><strong>SQLAgentReaderRole<\/strong> &#8211; Users in this role get all the privileges of the<strong><\/strong><strong>SQLAgentUserRole<\/strong>, i.e. they get access to owned jobs. In addition to that, they can also view (but not modify or execute) all jobs on SQL Server Agent, irrespective of ownership. <em>Grant this role when you want users to be able to view<\/em><em>, but not execute,<\/em><em> all jobs in the system, but modify\/execute only jobs owned by them<\/em>.<\/li>\n<li><strong>SQLAgentOperatorRole<\/strong> &#8211; Users in this role get all the privileges of the <strong>SQLAgentReaderRole<\/strong>. In addition to that, they can also execute, or enable\/disable any job in the system. However, users in this role can modify only owned jobs. <em>Grant this role for super users who can view\/execute all jobs on the system.<\/em><\/li>\n<\/ul>\n<p> \tAlways start by granting users the most restrictive role &#8211; <strong>SQLAgentUserRole<\/strong>, and upgrade membership to higher roles if required. Use the below table to determine the type of access you should grant: <\/p>\n<div class=\"table\">\n<table>\n<tbody>\n<tr>\n<td>                 \tAction                 <\/td>\n<td>                 \tSQLAgentUserRole                 <\/td>\n<td>                 \tSQLAgentReaderRole                 <\/td>\n<td>                 \tSQLAgentOperatorRole                 <\/td>\n<\/tr>\n<tr>\n<td>                 \tCreate\/modify\/delete                 <\/td>\n<td>                 \tOnly owned jobs                 <\/td>\n<td>                 \tOnly owned jobs                 <\/td>\n<td>                 \tOnly owned jobs                 <\/td>\n<\/tr>\n<tr>\n<td>                 \tView List                 <\/td>\n<td>                 \tOnly owned jobs                 <\/td>\n<td>                 \tAll jobs                 <\/td>\n<td>                 \tAll jobs                 <\/td>\n<\/tr>\n<tr>\n<td>                 \tEnable\/Disable                 <\/td>\n<td>                 \tOnly owned jobs                 <\/td>\n<td>                 \tOnly owned jobs                 <\/td>\n<td>                 \tAll jobs                 <\/td>\n<\/tr>\n<tr>\n<td>                 \tView Properties                 <\/td>\n<td>                 \tOnly owned jobs                 <\/td>\n<td>                 \tAll jobs                 <\/td>\n<td>                 \tAll jobs                 <\/td>\n<\/tr>\n<tr>\n<td>                 \tEdit Properties                 <\/td>\n<td>                 \tOnly owned jobs                 <\/td>\n<td>                 \tOnly owned jobs                 <\/td>\n<td>                 \tOnly owned jobs                 <\/td>\n<\/tr>\n<tr>\n<td>                 \tStart \/ Stop                 <\/td>\n<td>                 \tOnly owned jobs                 <\/td>\n<td>                 \tOnly owned jobs                 <\/td>\n<td>                 \tAll jobs                 <\/td>\n<\/tr>\n<tr>\n<td>                 \tView job history                 <\/td>\n<td>                 \tOnly owned jobs                 <\/td>\n<td>                 \tAll jobs                 <\/td>\n<td>                 \tAll jobs                 <\/td>\n<\/tr>\n<tr>\n<td>                 \tDelete job history                 <\/td>\n<td>                 \tNo                 <\/td>\n<td>                 \tNo                 <\/td>\n<td>                 \tOnly owned jobs                 <\/td>\n<\/tr>\n<tr>\n<td>                 \tChange Ownership                 <\/td>\n<td>                 \tNo                 <\/td>\n<td>                 \tNo                 <\/td>\n<td>                 \tNo                 <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h2>What service account to use<\/h2>\n<p> \tThe core of the SQL Server Agent infrastructure is the <strong>SQL Agent Service<\/strong>. This is a windows service that is responsible for executing the different types of job steps supported by SQL Server Agent. The <em>service account<\/em> defines the Microsoft Windows account used to execute the SQL Agent service. <\/p>\n<p> \tYou select an account for the SQL Server Agent service by using SQL Server Configuration Manager, where you can choose from the following options: <\/p>\n<ul>\n<li><strong><em>Local System<\/em><\/strong><strong><em><\/em><\/strong>&#8211; This is the NT AUTHORITY\\System account on the local machine. It is a member of the Windows <strong>Administrators<\/strong> group on the local machine, and therefore, is a member of the SQL Server <strong>sysadmin<\/strong> fixed server role. Since the account is a Windows administrator, it has permissions beyond what is required for running SQL Server Agent, and it is therefore not recommended to be used as a service account.<\/li>\n<li><strong><em>Local Service<\/em><\/strong><strong><em><\/em><\/strong>&#8211; not recommended. Has minimum privileges on local machine.<\/li>\n<li><strong><em>Network Service &#8211; <\/em><\/strong>not recommended. Has minimum privileges on local machine.<\/li>\n<li><strong><em>Windows Domain Account<\/em><\/strong> &#8211; You can also choose a windows domain account as the service account for SQL Server Agent. Using a windows domain account and granting it the necessary permissions is the best practice when choosing a service account. It is also recommended that this account <em>not<\/em> be a member of the Windows <strong>Administrators<\/strong> group.<\/li>\n<\/ul>\n<p> \tFurther, the service account is required to be a member of the SQL Server <strong>sysadmin<\/strong> fixed server role on the SQL Server instance. <\/p>\n<p> \tSQL Server Agent also supports proxies, which allows it to execute processes in the context of other windows users. Proxies are addressed in detail later in this article, but from a security perspective, the service account should have the following windows permissions to be able to support proxies: <\/p>\n<ul>\n<li>Permission to log on as a service (<strong>SeServiceLogonRight<\/strong>)<\/li>\n<li>Permission to replace a process-level token (<strong>SeAssignPrimaryTokenPrivilege<\/strong>) &#8211; this permission allows a windows account to launch a new process under a different user account. This permission enables the SQL Server Agent service account to launch processes that &#8220;run as&#8221; the user accounts defined in the proxy.<\/li>\n<li>Permission to bypass traverse checking (<strong>SeChangeNotifyPrivilege<\/strong>) &#8211; this permission allows a windows account to traverse a directory structure, even though the account may not have access on the individual levels of the directory tree. To understand why this is required, consider this example &#8211; SQL Server Agent is trying to execute an SSIS package residing on a shared folder <a>\\\\TOP_SECRET\\For_SQL_Agent.dtsx<\/a>. In this scenario, the service account is granted access only to the &#8220;For_SQL_Agent.dtsx&#8221; file, and does not have any access whatsoever to the &#8220;TOP_SECRET&#8221; folder. Since the agent service account has the bypass traverse checking permission, it can still traverse the directory structure to get to the .dtsx file, and execute the package.<\/li>\n<li>Permission to adjust memory quotas for a process (<strong>SeIncreaseQuotaPrivilege<\/strong>) &#8211; required so that SQL Server agent can adjust memory quotas for memory-intensive jobs.<\/li>\n<li>Permission to log on using the batch logon type (<strong>SeBatchLogonRight<\/strong>) &#8211; when executing scheduled tasks in the context of a different user, SQL Server Agent will first create a new &#8220;batch logon session&#8221; that runs in the security context of this user. A batch logon session is a session created without any interaction from the user, as opposed to an &#8220;interactive&#8221; logon session, which is created when a user physically logs on to the machine. This permission enables SQL Server Agent to create a batch logon session.<\/li>\n<\/ul>\n<p> \tNote that there are special considerations when setting up the service account for multiserver job processing. You can refer to the documentation <a href=\"http:\/\/technet.microsoft.com\/en-us\/library\/ms191543.aspx\">here<\/a> for a complete list of the permissions required.. <\/p>\n<h2>Who should own what job<\/h2>\n<p> \t<img decoding=\"async\" src=\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/imported\/1994-1-e9aca3fe-1a51-4de1-93e8-0291cf1a3422.png\" class=\"float-right\" alt=\"1994-1-e9aca3fe-1a51-4de1-93e8-0291cf1a3\" \/>Job ownership is an important concept in SQL Server Agent. <strong>SQL Server Agent<\/strong> sets the security context for job execution based on the role of the user owning the job. By default, SQL Server Agent executes job steps under the SQL Server Agent service account irrespective of job ownership, or under the context of a proxy account, as we will see later in this article. <\/p>\n<p> \tThe exception to this rule is T-SQL job steps, which execute under the security context of the job owner. If the job owner is a member of the <strong>sysadmin<\/strong> role, then the job step executes in the context of the SQL Server Agent service account. A common mistake when setting up jobs is to make &#8220;sa&#8221; the job owner &#8211; this will cause all T-SQL job steps to execute as the SQL Agent service account, which is a system administrator account. A better option is to set a non-sysadmin account as the job owner, and explicitly grant only the required database permissions to this account. <\/p>\n<p> \tIf you have a single instance of SQL Server Agent hosting jobs for multiple applications, you should consider using job ownership for access control of T-SQL steps. Each group of jobs for an application should be owned by an account specific to that application, which is granted access only to database objects relevant to that application. This approach will prevent jobs for one application inadvertently modifying database objects from another application. Access control for other types of job steps (SSIS, replication etc.) can be enforced by using proxies, as we will see later in this article. <\/p>\n<h2>Logging to file<\/h2>\n<p> \t<img decoding=\"async\" src=\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/imported\/1994-1-8e1a9d3f-b5c8-484a-a167-9e77870ba39b.png\" class=\"float-right\" alt=\"1994-1-8e1a9d3f-b5c8-484a-a167-9e77870ba\" \/>SQL Server Agent maintains job history for each job execution, which includes job start and end times, a log of the job activity etc. There are a couple of ways you can view job history: <\/p>\n<ul>\n<li>Right-click on the job in SSMS, and choose <em>View job history<\/em>, or,<\/li>\n<li>By querying the <em>msdb.dbo.sysjobhistory<\/em> table. The <em>View job history <\/em>option in SSMS internally queries this table to get the job history.<\/li>\n<\/ul>\n<p> \tOne of the problems with the <strong>sysjobhistory<\/strong> table is that it can store only up to a maximum of 4000 characters per log entry, because the <em>message<\/em> column in the table is defined as <em>nvarchar(4000)<\/em>. If this is exceeded, it may cause problems with subsequent job steps because errors will be lost. This simple test will illustrate the point: <\/p>\n<pre class=\"lang:tsql theme:ssms2012\">DBCC CHECKALLOC\nselect 1\/0 -expression that will trigger an error.\n<\/pre>\n<p> \tIn the above t-SQL, we execute the DBCC CHECKALLOC command to check disk space allocation consistency for the <em>msdb<\/em> database. The command also prints an allocation summary for each index and partition in each file, which will go past the 4000 character limit on most databases. At the end of the DBCC command, the job step in our test intentionally fails with a divide by zero error. Upon execution, the job will obviously fail, but you will never see the divide by zero error in the job history, because the error message gets truncated at 4000 characters. <\/p>\n<p> \tTo prevent this from happening, it is always a good practice to log your job output to a file. You can set this option from the <em>Advanced<\/em> tab on the job step, as shown in the figure. Setting this option will write all your job output to a text file, and enable you to look at the complete log with no limit on the number of characters. <\/p>\n<p> \tWhen choosing this option, ensure that the SQL Agent service account has write access to the log file. There is also an option to log to a table instead, which basically writes the same log entry to the <strong>msdb.dbo.sysjobstepslogs<\/strong> table instead of a file. <\/p>\n<p> \tIf you choose to write the log output to a file or a table, it is a good idea to setup an archiving mechanism to archive the log file or table &#8211; failure to do so may lead to situations where the log file or table uses up all your disk space and brings down your entire SQL Server instance. <\/p>\n<p class=\"illustration\"> <img decoding=\"async\" src=\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/imported\/1994-1-e08f1fa4-21a3-4de0-afb9-8dc924ed5692.png\" class=\"float-right\" alt=\"1994-1-e08f1fa4-21a3-4de0-afb9-8dc924ed5\" \/><\/p>\n<h2>Using Alerts<\/h2>\n<p> \tSQL Server Agent provides an alert system that allows database administrators to configure outgoing alerts for various system events. The alert can be used to notify database administrators about certain error conditions. It can also execute other SQL Server Agent jobs to fix the problem, or take other remedial action. <\/p>\n<h3> Setting up alerts for errors <\/h3>\n<p> \tYou can setup alerts to send out notifications when certain errors occur in the system. Alerts can be triggered when: <\/p>\n<ul>\n<li>An error with a predefined error number occurs<\/li>\n<li>An error with a predefined severity occurs<\/li>\n<li>An error containing a predefined text occurs<\/li>\n<\/ul>\n<p> \tSQL Server Agent reads the Windows application log periodically and checks if an error satisfying one of the above criteria has occurred. If it finds an entry, it initiates the action listed on the <em>Response<\/em> tab of the alert. <\/p>\n<p class=\"illustration\"> <img decoding=\"async\" src=\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/imported\/1994-1-b6b98099-3a0f-4625-b078-acc826c397a6.png\" class=\"float-right\" alt=\"1994-1-b6b98099-3a0f-4625-b078-acc826c39\" \/><\/p>\n<p> \tThe <em>Response<\/em> allows you to notify a database administrator of the situation via email. Or, if the problem can be fixed, the alert can be configured to execute another SQL Server Agent job to fix the problem. <\/p>\n<p> \t<strong><em>Note<\/em><\/strong> &#8211; It is important to remember that SQL Server Agent alerts are triggered only for errors that are logged to the windows application log. If you setup alerts for errors that are not logged to the windows log (such as the divide by zero error), your alert will never fire. If you explicitly want an error to be logged to the windows application log, you can call <em>RAISERROR<\/em> with the <em>LOG<\/em> option, which will log the error and fire any alerts configured to listen for the specific error. <\/p>\n<p> \tThe best practice is to configure alerts for errors with severity 19 to 25. Errors with severity greater than 19 are always logged to the event log, and the alert should be configured to notify the database administrator(s). <\/p>\n<p class=\"illustration\"> <img decoding=\"async\" src=\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/imported\/1994-1-058e11b5-9abc-47b8-9f50-ba9f601b6278.png\" class=\"float-right\" alt=\"1994-1-058e11b5-9abc-47b8-9f50-ba9f601b6\" \/><\/p>\n<h3>Setting up performance alerts<\/h3>\n<p> \tAnother useful feature of SQL Server Agent is the ability to send out alerts when certain performance counters are affected. Alerts can be configured to fire when certain performance counters values exceed\/equal\/go below a limit. For e.g., the accompanying screenshot shows an alert configured to fire when the tempdb log file size exceeds 1 GB. On the response screen, you can execute a SQL Server Agent job to truncate the log and fix the problem. <\/p>\n<p><\/p>\n<h2>USING PROXIES<\/h2>\n<p>SQL Server Agent uses <em>Proxies<\/em> to define the security context for job steps. Basically, a proxy is an object that provides SQL Server Agent access to stored credentials for a Windows user. When running a job step that is configured to use a proxy, SQL Server Agent impersonates the credentials defined in the proxy, and then runs the job step using that security context. <\/p>\n<p class=\"illustration\"> \t<img decoding=\"async\" src=\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/imported\/1994-1-edd60c5d-129e-4af4-914d-b7d40ab51d5c.png\" class=\"float-right\" alt=\"1994-1-edd60c5d-129e-4af4-914d-b7d40ab51\" \/><\/p>\n<p> \tSQL Server Agent uses <em>Subsystems<\/em> to define the security context for proxies. By default, SQL Server agent provides 11 subsystems, as shown in the figure. Each subsystem represents a type of external process that can be executed in a job step. <\/p>\n<p> \tBy default, all <em>T-SQL<\/em> job steps in SQL Server Agent execute using the account that owns the job. For job steps that execute processes in one of the other subsystems (e.g. SSIS, PowerShell etc.), the default execution account is the SQL Server Agent execution account. For job steps in non <em>T-SQL<\/em> subsystems, the SQL Server Agent service account would have to be granted access to these other subsystems as well. This is almost always a bad practice &#8211; it significantly increases the security risk if the service account is compromised. <\/p>\n<p> \tA better option is to configure a proxy for each subsystem, and grant the appropriate privileges to the proxy account. When a proxy is granted access to a subsystem, it becomes available to all job steps using that subsystem. <\/p>\n<h3> \tCreating a proxy for SSIS Package Execution <\/h3>\n<p> \tYou can follow these steps to create a proxy for the SSIS subsystem, and use it in job steps. <\/p>\n<ul>\n<li><strong>Create a credential<\/strong> &#8211; In SSMS, expand the <em>Security<\/em> node, and right-click on <em>Credentials<\/em>. Choose <em>New Credential<\/em> to launch the new credential dialog, and enter the credential name. In the <em>Identity<\/em> box, enter the name of the windows account that you will be using for the proxy &#8211; this is the account that SQL Server Agent will use when connecting to the external subsystem. Enter, and re-enter the account password to create the credential.     <img decoding=\"async\" src=\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/imported\/1994-1-74e63921-4f63-4259-948b-9e9fdd0d0913.png\" alt=\"1994-1-74e63921-4f63-4259-948b-9e9fdd0d0\" \/><\/li>\n<li><strong>Create the proxy<\/strong> &#8211; In SSMS, expand the <em>Proxies <\/em> node under <em>SQL Server Agent<\/em>. Right-click on the <em>SSIS Package Execution<\/em> node, and choose <em>New Proxy<\/em> to launch the new proxy dialog. Type in a proxy name. In the <em>Credential name<\/em> box, type in the name of the credential created earlier. In the <em>Active to the following subsystems<\/em> list, check the subsystems where the proxy can be used &#8211; you must first make sure that the credential used by the proxy has access to the selected subsystems. In the above screenshot, I added the proxy to the <em>SQL Server Integration Services Package<\/em> subsystem.     <img decoding=\"async\" src=\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/imported\/1994-1-b989c145-260f-4cd0-a169-415d65f1f026.png\" alt=\"1994-1-b989c145-260f-4cd0-a169-415d65f1f\" \/><\/li>\n<li><strong>Create the job<\/strong> &#8211; Right-click on the <em>Jobs<\/em> node under SQL Server Agent in SSMS to launch the New Job dialog. Enter a name for the job and navigate to <em>Steps <\/em>tab. On the <em>Steps<\/em> tab, add a new job step by clicking New, and enter a job step name. Under the <em>Type <\/em>dropdown, select <em>SQL Server Integration Services Package<\/em>, since we added the proxy to the SSIS subsystem.  Under the <em>Run As<\/em> drop down, you should automatically see two accounts &#8211; the SQL Server Agent Service account, and the proxy we just created. You can then select a package of your choice from either the SSIS Catalog or the file system. Once you have selected the SSIS package, hit Ok on the <em>New Job Step<\/em> and <em>New Job <\/em>dialogs to create the job.     <img decoding=\"async\" src=\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/imported\/1994-8d7d7e3d-aaed-4511-8b2b-6c9ad9ad7ead.png\" alt=\"1994-8d7d7e3d-aaed-4511-8b2b-6c9ad9ad7ea\" \/><\/li>\n<\/ul>\n<div class=\"indent\">\n<p>When you execute the job we created, SQL Server Agent actually impersonates the account used by the proxy, and executes the SSIS package under the security context of the impersonated account.     <\/p>\n<\/p><\/div>\n<h2>Conclusion<\/h2>\n<p> \tIn this article we discussed the security implications when choosing a service account for SQL Server Agent, and looked at the security permissions that should be granted to the service account. We also delved into setting up job visibility for different users by adding them to one of the 3 fixed database roles in MSDB, and we also touched upon the importance of the job owner. We also looked at the options available for logging in SQL Server Agent, and how this enables you to get over the 4000-character limit in log messages. We went over the different types of alerts that you can configure in SQL Server Agent. Lastly, we looked at the steps to setup proxies and configure your jobs to use proxies. <\/p>\n<p> \tI hope that these tips will enable you to create a secure and efficient SQL Server Agent environment. <\/p>\n<\/p><\/div>\n","protected":false},"excerpt":{"rendered":"<p>It is important to set up SQL Server Agent Security on the principles of &#8216;executing with minimum privileges&#039;, and ensure that errors are properly logged and alerts are set up for a comprehensive range of errors. SQL Server Agent allows fine-grained control of every job step that should allow tasks to be run entirely safely even if they occasionally need special privileges.&hellip;<\/p>\n","protected":false},"author":178164,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[143527],"tags":[5946,5947,4170,5948,4619,4179,4150,4151,5945],"coauthors":[],"class_list":["post-1813","post","type-post","status-publish","format-standard","hentry","category-database-administration-sql-server","tag-agent-jobs","tag-agent-roles","tag-database-administration","tag-proxies","tag-security","tag-source-control","tag-sql","tag-sql-server","tag-sql-server-agent"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/1813","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/178164"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=1813"}],"version-history":[{"count":5,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/1813\/revisions"}],"predecessor-version":[{"id":92226,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/1813\/revisions\/92226"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=1813"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=1813"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=1813"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=1813"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}