Inbox Accounting Database Management

The Routing and Remote Access Service (RRAS) role in Windows Server is a popular VPN server choice for administrators deploying Windows Always On VPN. It is easy to configure, scales well, and is cost-effective. After installing RRAS, administrators can optionally enable inbox accounting to log historical data and generate user access and activity reports as described in Always On VPN RRAS Monitoring and Reporting.

Inbox Accounting Database

A Windows Internal Database (WID) is automatically installed and configured for data storage when inbox accounting is enabled.

WID is nothing more than a basic instance of Microsoft SQL Server. As such, the database will require periodic maintenance to perform optimally.

Inbox Accounting Database Management Scripts

I have created a series of PowerShell scripts to address the inbox accounting database management requirements for organizations using Windows Server RRAS. Scripts are available to perform the following inbox accounting database management tasks.

  • Optimize the inbox accounting database.
  • View the size of the inbox accounting database files.
  • Compress the size of the inbox accounting database.
  • Back up the inbox accounting database to a file on disk.
  • Restore the inbox accounting database from a backup file.
  • Move the inbox accounting database file to a different location.
  • Remove the inbox accounting database.

Optimize Database

A known issue with the inbox accounting database can result in high CPU and memory utilization for very busy RRAS VPN servers. Specifically, a crucial index is missing from one of the tables in the logging database. This issue persists in Windows Server 2022. To correct this issue, download and run the following PowerShell script on each RRAS VPN server in the organization.

Optimize-InboxAccountingDatabase.ps1

View Database Size

The database can grow rapidly depending on how busy the RRAS server is. Administrators can view the current database file sizes by downloading and running the following PowerShell script on the RRAS server.

Get-InboxAccountingDatabaseSize.ps1

Compress Database

Over time, the database can become fragmented, decreasing performance. Compressing the database can improve performance and result in significant recovery of disk space. To compress the inbox accounting database, download and run the following PowerShell script on each RRAS server in the organization.

Compress-InboxAccountingDatabase.ps1

In this example, compressing the database reduced its size by more than 8MB, resulting in a nearly 70% reduction in disk space usage.

Backup Database

Administrators may wish to back up the inbox accounting database before purging older records from the inbox accounting database. Also, backing up the database preservers access records when migrating to a new server. To back up the inbox accounting database, download and run the following PowerShell script on each RRAS server in the organization.

Backup-InboxAccountingDatabase.ps1

Restore Database

Naturally, to restore the inbox accounting database from a previous backup, administrators can download and run the following PowerShell script.

Restore-InboxAccountingDatabase.ps1

Restoring a database from backup will erase all records in the current database. It does not append. Proceed with caution!

Move Database Files

Inbox accounting database and log files are located in C:\Windows\DirectAccess\Db by default.

However, storing database and log files on the system drive is not ideal. A better alternative is to place the inbox accounting database and log files on a separate disk for optimum performance. To move the inbox accounting database, download and run the following PowerShell script on each VPN server in the organization.

Move-InboxAccountingDatabase.ps1

Moving inbox accounting files may not be formally supported by Microsoft. Use caution when making this change.

Remove Database

Occasionally an inbox accounting database becomes corrupt and can no longer be managed. If this happens, completely removing the database is required. It is essential to know that simply disabling and re-enabling inbox accounting on the VPN server does not delete the database. To delete the database completely, download and run the following PowerShell script.

Remove-InboxAccountingDatabase.ps1

PowerShell Module

To simplify things, the PowerShell scripts described in this article are available in a PowerShell module that can be installed from the PowerShell gallery using the following command.

Install-Module InboxAccountingDatabaseManagement

Additional Information

Windows Always On VPN RRAS Inbox Accounting Database Management PowerShell Module

Windows Always On VPN RRAS Monitoring and Reporting

Windows Always On VPN PowerShell Scripts on GitHub

DirectAccess Inbox Accounting Database Optimization

DirectAccess Inbox Accounting Database OptimizationRecently I wrote about an issue with DirectAccess servers exhibiting high SQL Server CPU usage. In that article I demonstrated a way to resolve the issue by adding a crucial index to a table in the remote access inbox accounting database. The process was a bit involved and required downloading third-party tools to make configuration changes on the DirectAccess server.

Going forward, making these changes will now be much easier. Microsoft has published guidance for optimizing the remote access inbox accounting database using PowerShell. They’ve also provided scripts to back up the database and to confirm that optimization has been implemented.

For more information and to download the remote access inbox accounting database optimization PowerShell scripts, click here.

DirectAccess SQL Server High CPU Usage

UPDATE – March 14, 2016: Microsoft has published official guidance for implementing the changes outlined in this article using PowerShell. Details here.

Introduction

DirectAccess SQL Server High CPU UsageRADIUS and Inbox accounting are the two supported logging options for DirectAccess in Windows Server 2012 R2. When Inbox accounting is selected, a Windows Internal Database (WID) is provisioned. Part of the base operating system, WID is functionally similar to SQL Server Express.

SQL Server Utilization Issues

Over the last few months I’ve had a few customers reach out to me with a peculiar performance issue. For customers with very busy DirectAccess servers, where those servers have also been configured to use Inbox accounting, they’ve reported observing unusually high CPU utilization on the sqlservr.exe process.

DirectAccess SQL Server High CPU Usage
Image courtesy Thomas Vuylsteke. Used with permission. – setspn.blogspot.com

As luck would have it, Thomas Vuylsteke, a Microsoft Platforms Premiere Field Engineer (PFE), had already identified the issue and a workaround. Thomas traced the source of high CPU utilization on the sqlservr.exe process to a missing index on a session state table in the DirectAccess accounting database. If you are interested in learning how he performed the troubleshooting to identify and resolve this problem, you can read his entire blog post here.

Resolution

To resolve this issue, create an index on the Session Table in the DirectAccess database. Changes to WID must be made locally, as it is not remotely manageable. WID does not include a management interface, which means the SQL Server management tools would normally have to be installed. However, I’m not a fan of installing any extraneous software on the DirectAccess server, so thankfully one of the readers of Thomas’ excellent article on this subject, Fredrik Elmqvist, provided a very helpful alternative. Fredrik suggesting using the HeidiSQL tool, for which a fully portable version exists. This allows for changes to be made to the WID database without having to install any additional software.

Changes to WID

Begin by downloading the portable version of HeidiSQL here. Next, log on to the DirectAccess server as the local administrator. It is crucial that you must be the local administrator, not just a local or domain user with local administrator privileges. Extract the files from the download and copy them to the DirectAccess server, then follow these steps:

  1. Double-click heideisql.exe to launch the management tool.
  2. Click on New and then for the Network Type select Microsoft SQL Server (named pipe).
  3. For the Hostname / IP: enter \\.\pipe\MICROSOFT##WID\tsql\query.
  4. Select the option to Use Windows Authentication.
  5. Click Open to continue.DirectAccess SQL Server High CPU Usage
  6. Click the Query tab in the center console window and enter the following commands:
    Use RaAcctDb
    Create NonClustered Index IdxSessionTblSessionState on SessionTable (SessionState,ConnectionID)
  7. Click the Run icon in the tool bar or press F9. This will execute the code and create the missing index on the Session Table in the DirectAccess database.DirectAccess SQL Server High CPU Usage
  8. Confirm the index was created by clearing the previous query or creating a new query and then entering the following commands:
    select * from sys.indexes
    where name like ‘idx%’
    order by name ascDirectAccess SQL Server High CPU Usage

Summary
Once the change has been made, sqlservr.exe CPU utilization should return to normal. If you have multiple DirectAccess servers configured in a load-balanced array or in a multisite configuration, be sure to repeat these steps on each DirectAccess server in the organization.