Set-DbaAgentJobOwner

Want to see the source code for this command? Check out Set-DbaAgentJobOwner on GitHub.
Want to see the Bill Of Health for this command? Check out Set-DbaAgentJobOwner.

Synopsis

Updates SQL Server Agent job ownership to ensure jobs are owned by a specific login

Description

This function standardizes SQL Agent job ownership by updating jobs that don't match a specified owner login. It's commonly used for security compliance, post-migration cleanup, and environment standardization where consistent job ownership is required.

By default, jobs are reassigned to the 'sa' account (or the renamed sysadmin account if 'sa' was renamed), but you can specify any valid login. The function automatically detects renamed 'sa' accounts by finding the login with ID 1.

Only local (non-MultiServer) jobs are processed by default, though you can target specific jobs or exclude certain ones. The function validates that the target login exists and prevents assignment to Windows groups, which cannot own SQL Agent jobs.

Jobs already owned by the target login are skipped, and detailed status information is returned for each job processed.

Best practice reference: https://www.itprotoday.com/sql-server-tip-assign-ownership-jobs-sysadmin-account

Syntax

Set-DbaAgentJobOwner
    [[-SqlInstance] <DbaInstanceParameter[]>]
    [[-SqlCredential] <PSCredential>]
    [[-Job] <Object[]>]
    [[-ExcludeJob] <Object[]>]
    [[-InputObject] <Job[]>]
    [[-Login] <String>]
    [-EnableException]
    [-WhatIf]
    [-Confirm]
    [<CommonParameters>]

Examples

Example: 1

PS C:\> Set-DbaAgentJobOwner -SqlInstance localhost

Sets SQL Agent Job owner to sa on all jobs where the owner does not match sa.

Example: 2

PS C:\> Set-DbaAgentJobOwner -SqlInstance localhost -Login DOMAIN\account

Sets SQL Agent Job owner to 'DOMAIN\account' on all jobs where the owner does not match 'DOMAIN\account'. Note
that Login must be a valid security principal that exists on the target server.

Example: 3

PS C:\> Set-DbaAgentJobOwner -SqlInstance localhost -Job job1, job2

Sets SQL Agent Job owner to 'sa' on the job1 and job2 jobs if their current owner does not match 'sa'.

Example: 4

PS C:\> 'sqlserver','sql2016' | Set-DbaAgentJobOwner

Sets SQL Agent Job owner to sa on all jobs where the owner does not match sa on both sqlserver and sql2016.

Example: 5

PS C:\> Get-DbaAgentJob -SqlInstance vmsql | Where-Object OwnerLoginName -eq login1 | Set-DbaAgentJobOwner -TargetLogin login2 | Out-Gridview

Sets SQL Agent Job owner to login2 where their current owner is login1 on instance vmsql. Send result to gridview.

Optional Parameters

-SqlInstance

The target SQL Server instance or instances.

-SqlCredential

Login to the target instance using alternative credentials. Accepts PowerShell credentials (Get-Credential).
Windows Authentication, SQL Server Authentication, Active Directory - Password, and Active Directory - Integrated are all supported.
For MFA support, please use Connect-DbaInstance.

-Job

Specifies which SQL Agent jobs to update ownership for. Accepts job names as strings and supports tab completion from the target server.
Use this when you need to update ownership for specific jobs rather than processing all jobs on the instance.

-ExcludeJob

Specifies SQL Agent jobs to skip during the ownership update process. Accepts job names as strings with tab completion.
Useful for excluding critical jobs or jobs that must retain their current ownership for security or operational reasons.

-InputObject

Accepts SQL Agent job objects from the pipeline, typically from Get-DbaAgentJob output.
Use this for advanced filtering scenarios where you need to process jobs based on complex criteria like owner, category, or schedule properties.

-Login

Specifies the target login account that should own the SQL Agent jobs. Defaults to 'sa' or automatically detects the renamed sysadmin account (login ID 1).
Must be a valid SQL login or Windows account that exists on the server. Cannot be a Windows group as they cannot own SQL Agent jobs.

-EnableException

By default, when something goes wrong we try to catch it, interpret it and give you a friendly warning message.
This avoids overwhelming you with "sea of red" exceptions, but is inconvenient because it basically disables advanced scripting.
Using this switch turns this "nice by default" feature off and enables you to catch exceptions with your own try/catch.

-WhatIf

If this switch is enabled, no actions are performed but informational messages will be displayed that explain what would happen if the command were to run.

-Confirm

If this switch is enabled, you will be prompted for confirmation before executing any operations that change state.