I recently worked with a customer to help resolve an issue with Team Foundation Server where collection databases were not coming online following a service restart. While working on this issue, the following question was posed: "how can we identity the user(s) responsible for stopping, starting, and restarting SQL Server services?".

Preliminary investigation into using SQL Server audit functionality yielded no solution. Checking with Microsoft database specialists, they confirmed that the closest auditing SQL Server could provide for service restarts would tie that operation to the privileged 'sa' identity. Checking with one of Microsoft's Premier Field Engineers specializing in Security, Liju Varghese provided a quick overview on how to implement service level auditing.

The following sections provide details on the settings required at the operating system level to audit service management operations, in this case for the SQL Server service. This is done using group policy objects.

Prerequisites

Ensure the following prerequisites are met prior to proceeding:

• The Group Policy Editor must be available on the SQL Server machine. If you don’t already have it, you can install using Add Roles & Features wizard:

• Ensure you have sufficient permissions to perform the actions outlined in this document. This may include administrative rights on the local server hosting the SQL Server instance, and possibly domain administrative rights if you are configuring Group Policy Objects at the domain level.

The next section, Configuration Details, provides detailed steps on configuring your environment to track SQL Server service starts, stops, and restarts. If you are more interested in seeing the results of this configuration first, you can skip to the following section titled Testing the Configuration to see how service starts, stops, and restarts are reported.

Configuration Details

The first step in the process is to enable auditing SACL on the SQL Server service. This must be done on the server that is hosting the SQL Server service. To begin these steps, click on the Windows Start button, then search for and start the Group Policy Management application:

Navigate to the “Group Policy Objects” folder in your domain, right-click on that folder, and select the “New” menu item to create a new group policy object:

Provide a meaningful name for your new GPO and click “OK”:

Right-click on the domain, or suitable OU container to restrict the policy application to only your SQL Server machines, and select the “Link an Existing GPO…” menu option:

Select the newly created “SQL Server Policy” group policy object and click “OK” to link this object:

Confirm that the new “SQL Server Policy” object shows as a linked object to your domain or OU container:

Right-click on the newly created GPO folder and select the “Edit…” menu item:

The “Group Policy Management Editor” will appear next. Expand and locate the SQL Server service name along the following path: Computer Configuration → Policies → Windows Settings → Security Settings:

Right-click on your SQL Server service and select the “Properties” menu item, then complete the following dialog window to define a policy for this service:

Next, click the “Edit Security…” button to display the “Security for SQL Server” dialog window. From here, click on the “Advanced” button to display the “Advanced Security Settings” window. From this window, select the “Auditing” tab and then click the “Add” button to create a new audit setting:

In the next window, add “Authenticated Users” as a principal, set the type to “Success”, and check the following permissions: “Start, stop and pause”, “Write”, “Delete”:

In the previous window, you should now see the Success Audit entry like the following:

Enable “Object Access” auditing policies using the Group Policy Management Editor. Navigate to these settings along the following path: Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies → Object Access, as shown in the following image:

Once the steps outlined above have been completed, you are ready to test the configuration by stopping, starting, or restarting the SQL Server instance.

Testing the Configuration

Once the GPO configuration has been implemented, you can check the results of stopping, starting, or restarting the SQL Server instance using the following steps.

First, stop, start, or restart the SQL Server instance. There are multiple ways to do this, including: SQL Server Management Studio, the Services (services.msc) application, or from the command line (sc.exe). No matter which method is used, the identity of the user invoking the start, stop, restart operation will be available.

Next, start the Event Viewer application, and navigate to: Event Viewer (Local) → Windows Logs → Security and filter on Event ID 4656. You will see a list like the following:

Select each Event ID 4656 and look in the General tab for “Accesses” text labeled either “Stop the service” or “Start the service” for the MSSQLSERVER service, like the following:

The domain and username are displayed in the “Subject” area as shown in the image above.

These events will appear for any direct stop, start, restart operation on the SQL Server. There is one other scenario we need to consider, where a SQL Server instance is restarted due to a complete server restart operation. In that scenario, the events described above will not be present.

To determine the user identity initiating a server restart, you can look in the Event Viewer (Local) → Windows Logs → Security section of the Event Viewer and filter by Event ID 1074. This provides information on the user initiating the server restart as shown in the following image:

Conclusion

Hopefully, this information will prove useful in your development and/or infrastructure management activities.

Until next time...

I do a lot of work with virtualized environments with Hyper-V virtual machines running in a Windows client operating system. I'll often have multiple VMs per environment, with startup dependencies between them. For example, a Team Foundation Server environment using domain authentication and a separate database tier will require 3 VMs, one for Active Directory, one for the SQL Server database, and one for the TFS application tier.

To serialize the startup of these virtual machines and ensure they start in a specific order, I've created the following PowerShell script:

[CmdletBinding()]
Param(
    [Parameter(Position=0)]
    [array]$list = @("AD", "SQL", "TFS")
)

$start = Get-Date
Write-Output "$(Get-Date $start -Format g) => Starting the following VMs: $list"

foreach ($item in $list)
{
    $name = "HV-DEMO-" + $item
    Write-Output ""
    Write-Output "Starting VM: $name"
    Start-VM -Name $name
    Write-Output "Waiting for heartbeat..."
    Wait-VM -Name $name -For Heartbeat
    Write-Output "VM $name started and accepting connections"
}

$finish = Get-Date
Write-Output "$(Get-Date $finish -Format g) => Finished in $(($finish - $start).Minutes) minutes $(($finish - $start).Seconds) seconds"

Saving this script to a local file named "start-tfs-vms.ps1" and then running it with no parameters (uses the default parameter values) displays the following output:

  
 Windows PowerShell
 Copyright (C) Microsoft Corporation. All rights reserved.

 PS C:\> start-tfs-vms.ps1
 1/9/2018 6:11 PM => Starting the following VMs: AD SQL TFS

 Starting VM: HV-DEMO-AD
 Waiting for heartbeat...
 VM HV-DEMO-AD started and accepting connections

 Starting VM: HV-DEMO-SQL
 Waiting for heartbeat...
 VM HV-DEMO-SQL started and accepting connections

 Starting VM: HV-DEMO-TFS
 Waiting for heartbeat...
 VM HV-DEMO-TFS started and accepting connections

 1/9/2018 6:11 PM => Finished in 0 minutes 42 seconds  

You can easily create another script named "stop-tfs-vms.ps1" that replaces usage of the Start-VM cmdlet with the Stop-VM cmdlet to reverse this operation. Note that you will probably want to change the order of the VM names so they stop in the reverse order.

Background

• Move or Clone Team Foundation Server from one hardware to another
• Move Team Foundation Server from one environment to another

"In some situations you might want to change the domain of a TFS deployment as well as its hardware. Changing the domain is an environment-based move, and you should never combine the two move types. First complete the hardware move, and then change the environment."

User Mapping File

OldDomain,OldAccount,NewDomain,NewAccount
TFSDEV,Developer1,TFSPRD,Developer1
TFSDEV,Developer3,TFSPRD,Developer2

1. Remap TFS user identities
2. Remap SharePoint user identities
3. Update SSRS user permissions

TFS Identities

tfs-change-identities.ps1

[CmdletBinding()]
param (
    [Parameter(Mandatory=$true, Position=0)]
    [string] $UserMapFile,
    [Parameter(Position=1)]
    [string] $TfsConfig = "C:\Program Files\Microsoft Team Foundation Server 14.0\Tools\TfsConfig.exe"
)

if (-Not (Test-Path $TfsConfig))
{
    Write-Error "TfsConfig.exe file does not exist in the specified location"
    return
}

if (-Not (Test-Path $UserMapFile))
{
    Write-Error "User map file does not exist in the specified location"
    return
}

$usermap = Import-Csv $UserMapFile

foreach ($user in $usermap)
{
    Write-Host "Changing $($user.OldDomain)\$($user.OldAccount)" -NoNewline
    Write-Host " to $($user.NewDomain)\$($user.NewAccount)"

    & $TfsConfig Identities /change `
        /fromdomain:$($user.OldDomain) `
        /todomain:$($user.NewDomain) `
        /account:$($user.OldAccount) `
        /toaccount:$($user.NewAccount)
}

PS C:\> .\tfs-change-identities.ps1 c:\docs\usermap.csv
Changing TFSDEV\Developer1 to TFSPRD\Developer1
Account Name           Exists (see note 1)  Matches (see note 2)
TFSPRD\Developer1      True                 False                  Changed
1 security identifier(s) (SIDs) were changed in Team Foundation Server.
== NOTES ==
(1) The Exists column indicates whether the listed account exists in Windows. For the List mode of the command, this is the account stored in Team Foundation Server. For the Change mode, it is the target of the change.
(2) The Matches column indicates whether the SID stored in Team Foundation Server matches with Windows.

SharePoint Identities

sp-change-identities.ps1

[CmdletBinding()]
param (
    [Parameter(Mandatory=$true, Position=0)]
    [string] $WebAppUrl,
    [Parameter(Mandatory=$true, Position=1)]
    [string] $UserMapFile
)
$ErrorActionPreference = "Stop"
Add-PSSnapIn "Microsoft.SharePoint.Powershell"

$moveErrors = $null
$usermap = Import-Csv $UserMapFile

$users = Get-SPWebApplication $WebAppUrl | Get-SPSite | Get-SPWeb | Get-SPUser

foreach ($user in $users)
{
    $parts = $user.UserLogin.Split('\')
    if ($parts.Count -ne 2) { continue }
    $domain = $parts[0]
    $account = $parts[1]

    foreach ($entry in $usermap)
    {
        if ($domain -eq $entry.OldDomain -and $account -eq $entry.OldAccount)
        {
            $oldAlias = $domain + "\" + $account
            $newAlias = $entry.NewDomain + "\" + $entry.NewAccount
            Write-Host "Changing SharePoint user from [" -ForegroundColor Yellow -NoNewline
            Write-Host $oldAlias "] to [" $newAlias "]" -ForegroundColor Yellow
            Move-SPUser -Identity $user -NewAlias $newAlias -IgnoreSID -ErrorAction SilentlyContinue
        }
    }
}

PS C:\> .\sp-change-identities.ps1 https://tfs-prd-at/ .\usermap.csv

Changing SharePoint user from [TFSDEV\Developer1] to [TFSPRD\Developer1]
Changing SharePoint user from [TFSDEV\Developer3] to [TFSPRD\Developer2]

SSRS Permissions

ssrs-list-permissions.ps1

<#
    PowerShell script to iterate over non-inherited SSRS permissions.
    1. Change the $sourceFolderPath value if you want to start at a lower
       level than root of SSRS.
    2. Change the $InstanceName if this is not the SSRS default instance
#>
[CmdletBinding()]
param (
    [Parameter(Position=0)]
    [string] $sourceFolderPath = "/",
    [Parameter(Position=1)]
    [string] $InstanceName = ""
)

if ($InstanceName -eq "")
{
    $reportServerUri = "https://localhost/ReportServer/ReportService2010.asmx"
}
else
{
    $reportServerUri = "https://localhost/ReportServer_" + $InstanceName + "/ReportService2010.asmx"
}

$scriptDirectory = Split-Path $MyInvocation.MyCommand.Path
$outfile = $scriptDirectory + "\ssrs-list-permissions.csv"

Write-Host "SSRS web service:  " $reportServerUri -ForegroundColor Yellow
Write-Host "Working directory: " $scriptDirectory -ForegroundColor Yellow
Write-Host "Computer name:     " $env:COMPUTERNAME -ForegroundColor Yellow
Write-Host "Logged in as:      " $env:USERNAME -ForegroundColor Yellow

$inheritParent = $true
$output = @()

$proxy = New-WebServiceProxy -UseDefaultCredential -Uri $reportServerUri

$items = $proxy.ListChildren($sourceFolderPath, $true) `
    | Select-Object TypeName, Path, Name

foreach ($item in $items)
{
    Add-Member -InputObject $item -MemberType NoteProperty -Name RoleName -Value ''
    Add-Member -InputObject $item -MemberType NoteProperty -Name FullyQualifiedUserName -Value ''
    Add-Member -InputObject $item -MemberType NoteProperty -Name Domain -Value ''
    Add-Member -InputObject $item -MemberType NoteProperty -Name UserName -Value ''

    $needHeader = $true
    foreach ($policy in $proxy.GetPolicies($item.path, [ref]$inheritParent))
    {
        if ($inheritParent) { continue }

        if ($needHeader)
        {
            Write-Host
            Write-Host "Type: " $item.TypeName -ForegroundColor Yellow
            Write-Host "Path: " $item.Path -ForegroundColor Yellow
            Write-Host "Name: " $item.Name -ForegroundColor Yellow
            Write-Host "--------------------------------------------------"
            $needHeader = $false
        }

        Write-Host $policy.GroupUserName -NoNewline
        Write-Host " (" -NoNewline
        $needComma = $false
        foreach ($role in $policy.Roles)
        {
            if ($needComma) { Write-Host ", " -NoNewline } else { $needComma = $true }
            Write-Host $role.Name -ForegroundColor Green -NoNewline
            $temp = $item.PsObject.Copy();
            $temp.RoleName = $role.Name
            $temp.FullyQualifiedUserName = $policy.GroupUserName;
            $temp.Domain = $policy.GroupUserName.Split('\')[0]
            $temp.UserName = $policy.GroupUserName.Split('\')[1]
            $output += $temp;
            $temp.reset;
        }
        Write-Host ")"
    }
}

$output | Export-csv $outfile -NoTypeInformation;

Write-Host
Write-Host "Completed with output stored in: " $outfile
Write-Host

PS C:\> .\ssrs-list-permissions.ps1

Type:  Folder
Path:  /TfsReports/DefaultCollection/Agile
Name:  Agile

TFSDEV\Developer1 (Content Manager, Publisher)
TFSDEV\Developer3 (Browser)
Completed with output stored in: ssrs-list-permissions.csv

TypeName,Path,Name,RoleName,FullyQualifiedUserName,Domain,UserName
Folder,/TfsReports/DefaultCollection/Agile,Agile,Content Manager,TFSDEV\Developer1,TFSDEV,Developer1
Folder,/TfsReports/DefaultCollection/Agile,Agile,Publisher,TFSDEV\Developer1,TFSDEV,Developer1
Folder,/TfsReports/DefaultCollection/Agile,Agile,Browser,TFSDEV\Developer3,TFSDEV,Developer3

ssrs-change-permissions.ps1

<#
    The first parameter (ssrsPermissionsFile) is the file path to the output
      from the 'ssrs-list-permissions.ps1' script run in the old domain.
    The second parameter (UserMapFile) is the file path to the user mapping file.
    The third parameter (ssrsInstanceName) is the SSRS instance name. If running
      on the default SSRS instance, press <Enter> if prompted to supply
      an empty string value.
#>
[CmdletBinding()]
param (
    [Parameter(Mandatory=$true, Position=0)]
    [string] $ssrsPermissionsFile,
    [Parameter(Mandatory=$true, Position=1)]
    [string] $UserMapFile,
    [Parameter(Mandatory=$true, Position=2)]
    [AllowEmptyString()]
    [string] $ssrsInstanceName
)

if ($ssrsInstanceName -eq "")
{
    $reportServerUri = "https://localhost/ReportServer/ReportService2010.asmx"
}
else
{
    $reportServerUri = "https://localhost/ReportServer_" + $ssrsInstanceName + "/ReportService2010.asmx"
}

if (-Not (Test-Path $ssrsPermissionsFile))
{
    Write-Error $ssrsPermissionsFile " file does not exist in the specified location"
    return
}

if (-Not (Test-Path $UserMapFile))
{
    Write-Error $UserMapFile " file does not exist in the specified location"
    return
}

Write-Host "Loading SSRS permissions (old domain) from file: " $ssrsPermissionsFile
$permissions = Import-Csv $ssrsPermissionsFile

Write-Host "Loading user mapping file: " $UserMapFile
$usermap = Import-Csv $UserMapFile

$lookup = @{}
$usermap | % { $key = $_.OldDomain + "\" + $_.OldAccount; $lookup[$key] = $_ }

$inheritParent = $true

Write-Host "Connecting to SSRS web service: " $reportServerUri
$proxy = New-WebServiceProxy -UseDefaultCredential -Uri $reportServerUri
$type = $proxy.GetType().Namespace
$policyType = "{0}.Policy" -f $type
$roleType = "{0}.Role" -f $type

foreach ($permission in $permissions)
{
    $key = $permission.FullyQualifiedUserName
    $user = $lookup[$key]

    if ($user -ne $null)
    {
        $identity = $user.NewDomain + "\" + $user.NewAccount

        $message = "Retrieving policies for user '{0}' on '{1}'" -f $identity, $permission.Path
        Write-Host $message -ForegroundColor Yellow

        $policies = $proxy.GetPolicies($permission.Path, [ref]$inheritParent);

        $policy = $policies |
            where { $_.GroupUserName -eq $identity } |
            select -First 1

        if (-not $policy)
        {
            $policy = New-Object ($policyType)
            $policy.GroupUserName = $identity
            $policy.Roles = @()
            $policies += $policy
            $message = "Creating policy for user: '{0}'" -f $identity
            Write-Host $message -ForegroundColor Cyan
        }
 
        $role = $policy.Roles |
            where { $_.Name -eq $permission.RoleName } |
            select -First 1

        if (-not $role)
        {
            $role = New-Object ($roleType)
            $role.Name = $permission.RoleName
            $policy.Roles += $role
            $message = "Adding user '{0}' to role '{1}'" -f $identity, $permission.RoleName
            Write-Host $message -ForegroundColor Cyan
        }

        $message = "Saving policies for user '{0}' on '{1}'" -f $identity, $permission.Path
        Write-Host $message -ForegroundColor Cyan
        $proxy.SetPolicies($permission.Path, $policies);
    }
    else
    {
        $message = "'{0}' not found in user mapping file" -f $key
        Write-Host $message -ForegroundColor Red
    }
}

PS C:\> C:\Scripts\ssrs-change-permissions.ps1 .\ssrs-list-permissions.csv .\usermap.csv ""
Loading SSRS permissions (old domain) from file: ssrs-list-permissions.csv
Loading user mapping file: usermap.csv
Connecting to SSRS web service: https://localhost/ReportServer/ReportService2010.asmx
Retrieving policies for user 'TFSPRD\Developer1' on '/TfsReports/DefaultCollection/Agile'
Creating policy for user: 'TFSPRD\Developer1'
Adding user 'TFSPRD\Developer1' to role 'Content Manager'
Saving policies for user 'TFSPRD\Developer1' on '/TfsReports/DefaultCollection/Agile'
Adding user 'TFSPRD\Developer1' to role 'Publisher'
Saving policies for user 'TFSPRD\Developer1' on '/TfsReports/DefaultCollection/Agile'
Retrieving policies for user 'TFSPRD\Developer2' on '/TfsReports/DefaultCollection/Agile'
Creating policy for user: 'TFSPRD\Developer2'
Adding user 'TFSPRD\Developer2' to role 'Browser'
Saving policies for user 'TFSPRD\Developer2' on '/TfsReports/DefaultCollection/Agile'

Conclusion

Details on the March 7th & 8th launch event are available here: https://launch.visualstudio.com/

https://azure.microsoft.com/en-us/updates/get-early-access-to-new-portal-features-2/

Of particular interest is the new Subscription Usage + quotas view that displays a graphical view of your subscription’s current limits:

You can filter the list by service, provider, and location, and restrict the view to only those items currently used or all items. The page has a handy link to initiate a quota increase request. Additionally, you can sort by the Usage column in descending order to get an idea of the quotas that are nearing their limit. This is extremely useful for planning future usage increases.

The preview portal is located here: preview.portal.azure.com

For more detailed information on quotas, please see the following documentation: Azure subscription and service limits, quotas, and constraints