SiteAudit Web Reports Overview

SiteAudit 8.5 Web Reports Overview

Introduction

SiteAudit 8.5 introduces Web Reports, a browser-based reporting application designed to make SiteAudit information easier to access, analyze, and export. The feature replaces the Reporting WebSite that was included with SiteAudit versions 8.1.2.4 and earlier and consolidates reporting activities into a single web-based workflow. Rather than requiring users to install SiteAudit Viewer or SiteAudit Control Panel on every workstation used for reporting, Web Reports allows authorized users to access reporting functionality from a supported browser.

The Web Reports experience combines several activities that previously might have required separate applications or processes. Depending on the deployment model and the user’s permissions, a report user can select one or more SiteAudit customer databases, choose the information to include in a report, create and save reusable templates, generate results directly in the browser, and export those results to CSV or Microsoft Excel XLSX files. Hosted users can potentially report across multiple customer environments, while OnSite users generally work with a single local SiteAudit database.

Web Reports is therefore intended to provide both a simplified user experience and a centralized reporting platform. It allows organizations to give users access to reporting functions without necessarily giving them access to broader SiteAudit administration or monitoring tools. This separation can be particularly valuable for users whose responsibilities are limited to reviewing fleet information, analyzing counters or consumables, examining incidents, or providing data to other business systems.

The application requires the .NET 10 Framework, and OnSite environments have additional licensing, service, network, and SQL Server requirements that must be satisfied before Web Reports can operate.

Intended Users

The Web Reports guide applies to three primary types of users: Hosted administrators, OnSite administrators, and report users.

Hosted administrators are responsible for managing access to customer databases and reporting users in a SiteAudit Hosted environment. Because Hosted reporting may span multiple customer databases, administrators determine which customer environments a particular user is allowed to access.

OnSite administrators are responsible for installing, licensing, configuring, and maintaining Web Reports inside their own infrastructure. Their responsibilities can include configuring the Reporting Local Service, ensuring SQL Server connectivity, selecting the appropriate authentication method, making the service reachable over the network, and maintaining any firewall or HTTPS certificate configuration required for remote browser access.

Report users interact primarily with the Web Reports interface. Their responsibilities include selecting customers when applicable, creating or copying report templates, choosing report fields, generating reports, reviewing the results, and exporting data.

This separation of roles reflects the overall architecture of Web Reports. Administrative functions remain under the control of technical or SiteAudit administrators, while everyday reporting tasks can be delegated to users who do not require access to the full SiteAudit Viewer or Control Panel environment.

Hosted and OnSite Deployment Models

Web Reports supports both SiteAudit Hosted and SiteAudit OnSite deployments. Although the reporting interface and report-generation concepts are similar, the installation, customer-selection, authentication, and infrastructure requirements differ.

Hosted Deployments

In a Hosted environment, Web Reports is provided as part of the SiteAudit Hosted infrastructure and normally does not require the reporting user to perform a local application or service installation. Users access the reporting site through the SiteAudit Management Server.

One of the major capabilities of Hosted Web Reports is the ability to work with multiple customer databases. A user who has been authorized to access several SiteAudit customers can select one or more of those customers when preparing a report. This allows a single reporting operation to span a subset of customers or, where access permits, an entire customer base.

Access is controlled through the user’s SiteAudit account and Microsoft Entra ID authentication. Consequently, the customers available in Web Reports are determined by the permissions associated with the authenticated user. A user does not automatically gain access to all customer databases merely by being able to sign in to Web Reports.

OnSite Deployments

An OnSite deployment runs Web Reports on a server or workstation within the customer’s own environment. Unlike Hosted installations, which may include many customer databases, OnSite Web Reports normally works with a single SiteAudit customer database. Because only one database is configured, the customer-selection step can be handled automatically and may not appear during report creation.

An OnSite installation requires several components and prerequisites. These include a Web Reports license, the Web Reports application itself, the Netaphor SiteAudit Reporting Local Service, the .NET 10 Framework, network access to the SiteAudit SQL Server database, and suitable SQL Server credentials and database permissions.

These requirements mean that an OnSite deployment is more dependent on the local IT environment than a Hosted deployment. The administrator must ensure that the reporting server can communicate with SQL Server, that the Windows service is configured appropriately for the chosen database authentication method, and that report users can reach the Web Reports web interface.

OnSite Licensing

Web Reports is a licensed SiteAudit feature in an OnSite environment. Before users can begin using the application, the SiteAudit installation must be licensed for Web Reports.

The licensing process begins in SiteAudit Viewer. The administrator opens Help > About, locates the SiteAudit Viewer User ID, and provides that ID to the SiteAudit administrator or an authorized Netaphor representative. Once the appropriate license has been applied, the applicable SiteAudit services or applications may need to be restarted if directed by the administrator.

Licensing should therefore be treated as an installation prerequisite rather than a user-level configuration step. If Web Reports has been installed but is unavailable or cannot be activated, administrators should first confirm that the SiteAudit environment has the appropriate license.

Reporting Local Service and SQL Server Connectivity

The Netaphor SiteAudit Reporting Local Service is an important component of an OnSite installation. It is created when Web Reports is installed and is responsible for operations that require access to the SiteAudit SQL Server database.

The Windows account used by the service depends on the authentication method used to connect to SQL Server.

SQL Server Authentication

When Web Reports uses SQL Server Authentication, the Reporting Local Service should normally run under the Local System account. This is both the default and preferred configuration for SQL Server Authentication.

In this model, the database credentials are provided through the SQL Server authentication configuration rather than through the Windows identity of the service. Consequently, the Windows service itself normally does not need to run under a specially created domain account.

Windows Authentication

The requirements are different when Web Reports uses Windows Authentication. In that situation, the Windows identity running the Reporting Local Service becomes part of the SQL Server authentication process.

The service must therefore run under a Windows user or service account that SQL Server recognizes and that has the appropriate rights to connect to the SiteAudit database. According to the guide, the account should have the required database-owner access, typically through the db_owner database role. That account must also be configured as the Log On As identity for the Reporting Local Service.

A dedicated service account is recommended whenever possible. The broader security principle is to grant only those permissions required for Web Reports to operate. If the service account is changed, the Reporting Local Service must be restarted so that the new credentials take effect.

The distinction between SQL Server Authentication and Windows Authentication is especially important during troubleshooting. A service configured correctly for one authentication model may fail completely if the database configuration is changed to another model without a corresponding change to the service identity.

Accessing Web Reports

Web Reports is accessed through a supported browser, but the URL depends on whether the deployment is Hosted or OnSite.

Hosted Access

Hosted users access Web Reports through their SiteAudit Management Server. If, for example, the Management Server is netaphorabc.com, the example Web Reports URL is:

https://netaphorabc.com/reportingserver

The actual address may vary by environment, so users who do not know the correct URL should obtain it from their SiteAudit administrator.

OnSite Access

OnSite Web Reports uses HTTPS on port 2850 by default.

On the computer where Web Reports is installed, it can be accessed using:

https://localhost:2850

A user accessing the same system from another computer on the network can use either the server’s machine name or IP address:

https://<machinename>:2850

or

https://<ipaddress>:2850

For remote access to function, the client computer must be able to reach port 2850 on the Web Reports server. Firewall rules, DNS configuration, HTTPS certificates, routing, or other network controls may therefore need to be adjusted.

This distinction also provides a useful troubleshooting technique. If https://localhost:2850 works directly on the Web Reports computer but another computer cannot connect, the application itself is probably functioning and the problem is more likely related to firewall, DNS, certificate, or network configuration.

Signing In and Authentication

After navigating to the appropriate Web Reports address, the user may first need to acknowledge any warning, legal notice, or government-use disclaimer presented by the environment. The user then signs in using an authorized account.

Where Microsoft Entra ID single sign-on is enabled, the authentication process may occur automatically. Once authenticated, access to reporting data remains limited to the customer databases for which the account has been authorized.

Users should sign out through the account menu when their session is complete, particularly when working from a shared computer.

Authentication therefore serves two purposes: establishing the user’s identity and controlling which SiteAudit customer content the user can access.

The Web Reports Dashboard

The dashboard is the primary starting point for reporting activity. It displays report templates available to the signed-in user.

Templates can include predefined SiteAudit templates, custom templates created by the user, and templates that the user has marked as favorites.

Predefined Templates

Predefined templates are identified by a lock icon. These templates cannot be edited directly. Instead, a user who wants to modify a predefined report must make a copy, give that copy a new name, and edit the resulting private template.

This approach protects the original predefined template while allowing users to customize the report structure to meet their own needs.

Custom Templates

Users can also create new templates from scratch rather than beginning with an existing report.

The dashboard provides controls for searching and sorting templates, marking frequently used reports as favorites, copying templates, and renaming custom templates.

The dashboard is therefore both a reporting launch point and a lightweight report-template management environment.

Selecting Customers

Customer selection is one of the areas where Hosted and OnSite behavior differs most significantly.

Hosted Customer Selection

Hosted users may have access to multiple customer databases. When opening or creating a report template, they can search for customers by customer name or database name, apply filters, select one or more customers, and then continue to report-field selection.

The customer list may support filtering by information such as:

• Billing type
• Number of days monitored
• Expiration date
• Managed-device count
• Customer name
• Database name

A Column Chooser allows the user to control which customer attributes are visible in the customer-selection interface.

Depending on the version and user permissions, the customer list itself can also be exported to CSV or XLSX.

The ability to select several customers is central to Hosted Web Reports. It makes it possible to create cross-customer reports without separately connecting to and reporting from every SiteAudit database.

OnSite Customer Selection

An OnSite environment normally contains a single customer database. Because there is no customer choice to make, that database is selected automatically and the customer-selection screen may be omitted entirely.

Report Data Categories

Web Reports allows report templates to combine information from several SiteAudit data categories. The primary categories described in the guide are Inventory, Lifetime Counters, Consumables, and Incidents.

Inventory

Inventory fields describe the device and its configuration. Examples include device type, manufacturer, model, firmware, IP address, department, managed status, and alert email address.

Inventory data provides the fundamental identifying and organizational information needed to understand which devices appear in the report.

Lifetime Counters

Lifetime Counter fields represent cumulative usage information. Examples include black-and-white count, color count, and total count.

These values can be combined with Inventory information to create reports focused on fleet usage, total page volume, or device activity.

Consumables

Consumables fields provide information about toner, ink, drums, maintenance kits, and related supplies. Available information can include the consumable description, type, current level, and estimated number of days remaining.

Consumables reporting can therefore be used to identify devices that may soon require toner or other maintenance-related supplies.

Incidents

Incident fields describe alerts and device conditions. Example fields include incident severity, alert description, and incident or alert details.

These fields enable reports that emphasize operational issues or devices requiring attention.

Important Report-Design Limitation

One of the most important rules in the guide concerns the relationship between Consumables and Incidents.

A report template may include:

Inventory + Lifetime Counters + Consumables

or:

Inventory + Lifetime Counters + Incidents

However, a template should not include both Consumables and Incidents at the same time.

The reason is the underlying data relationship. A single device can have several consumables and several incidents. When both categories are joined into the same report, multiple records on each side can match the same device, causing the number of rows to multiply.

For example, conceptually, if a device has several consumable records and several incident records, the report may produce a combination of those records rather than a single device-level row. The result can contain unexpectedly repeated information and may be difficult for users to interpret.

This is not described simply as a cosmetic issue. It is a fundamental report-design consideration. When users see unexpectedly repeated rows, one of the first things they should check is whether the template contains both Consumables and Incidents.

Creating a Custom Report Template

The process for creating a custom template follows a straightforward sequence.

The user begins at the dashboard and selects the option to create a new template. A descriptive template name is entered, followed by customer selection when applicable. The user then chooses the required report fields, arranges or configures those fields as needed, saves the template, and selects Generate to run the report.

The guide recommends choosing template names that clearly identify the purpose of the report. Examples include:

• Monthly Fleet Inventory
• All Customers – Lifetime Counters
• Low Consumables by Customer
• Critical Device Incidents

Clear naming becomes increasingly important as the number of saved templates grows. A meaningful name allows users to find frequently used reports without having to open each template to determine its purpose.

Managing Custom Templates

Custom templates can be managed directly from the dashboard. Depending on permissions, users can rename templates, copy templates, search the template list, sort templates, and add or remove templates from favorites.

A significant limitation in SiteAudit 8.5.0.0 is that custom templates are private to the user who created them. They cannot be directly shared with another Web Reports user.

If another user needs a similar report, that individual must create or copy a template under their own account.

This behavior is important for administrators and teams to understand. A report template created by one user should not be treated as an organization-wide shared resource in version 8.5.0.0.

Predefined templates provide a common baseline, but customized versions belong to the individual user account.

Generating Reports

Once the customers and fields have been selected, the user can generate the report.

The normal sequence is to save the template if necessary, select Generate, and allow the system to retrieve and assemble the requested information. The results are displayed directly in the browser.

Report-generation time can vary considerably depending on the scope and complexity of the request. Factors identified in the guide include:

• The number of customers selected
• The number of devices in each database
• The number and type of report fields
• Network performance
• Database performance
• Whether Consumables or Incidents are included

When results appear, users can select a column heading to sort the visible information.

This means report performance should be evaluated in context. A large Hosted report spanning many customers and many devices will naturally require more work than a small report from a single OnSite database. Including data categories such as Consumables or Incidents can further increase the amount of information the reporting system must retrieve and process.

Exporting Results

Although reports can be reviewed directly in the browser, Web Reports also supports exporting results for use elsewhere.

Two export formats are available:

CSV provides a simple text-based data format that can be opened or processed by a broad range of applications.

XLSX creates a Microsoft Excel-compatible workbook for users who want to review or manipulate the information in spreadsheet software.

To export data, the user first generates and reviews the report, selects Export, chooses either CSV or XLSX, and saves the resulting file.

The exported data reflects the report fields and customer selections defined by the template.

Exporting therefore provides a bridge between Web Reports and external analytical or business workflows. Users can use Web Reports to define and retrieve the required SiteAudit dataset and then work with that data in Excel or another system.

Checking the Installed Version

The About area within Web Reports provides version and application information. Users and administrators can use it to confirm the installed Web Reports version and review information such as third-party software licenses.

When contacting support, users should provide the exact version number shown in About rather than simply stating that they are using SiteAudit 8.5 or Web Reports.

Installers, prerequisites, and associated software are available from the Netaphor Downloads page.

Exact version information can be particularly important when troubleshooting because behavior, supported features, and limitations may differ between releases.

Relationship to SiteAudit Viewer and Control Panel

Web Reports does not eliminate SiteAudit Viewer or SiteAudit Control Panel from the SiteAudit product family. Instead, it reduces the need to install those applications on computers used only for reporting.

A user whose only responsibilities are viewing information and generating reports may be able to perform those tasks entirely through Web Reports. The browser becomes the reporting interface, and no local Viewer or Control Panel installation is required.

Viewer and Control Panel may still be necessary for administration, configuration, monitoring, or other SiteAudit functionality that Web Reports does not provide.

Web Reports users continue to authenticate through Microsoft Entra ID and remain restricted to the customer content that their accounts are permitted to access.

This distinction allows organizations to provide reporting access without necessarily exposing the broader set of SiteAudit administrative tools to every user.

Troubleshooting Web Reports

The guide provides several troubleshooting scenarios covering browser access, certificates, authentication, customer visibility, SQL Server connectivity, report design, and template management.

Web Reports Page Does Not Open

For an OnSite installation, administrators should verify that the URL begins with https:// and includes port 2850. They should also confirm that the Netaphor SiteAudit Reporting Local Service is running, that the computer name or IP address is correct, that firewall rules allow traffic on port 2850, and that the client can resolve the Web Reports server name.

The required .NET 10 Framework must also be installed.

A useful diagnostic step is to try:

https://localhost:2850

directly from the Web Reports computer.

If local access succeeds but a remote computer cannot connect, the problem is likely related to firewall configuration, DNS, the HTTPS certificate, or another network setting.

Browser Security Warnings

A browser may display a security warning when the OnSite server uses a certificate that is self-signed, expired, untrusted, or does not match the server name used in the URL.

Users should contact the OnSite administrator rather than simply ignoring the warning. The administrator may need to install or configure a trusted HTTPS certificate.

Sign-In Problems

If authentication fails, users or administrators should verify that the correct account is being used, that the account is enabled for Web Reports, that Microsoft Entra ID authentication is functioning, and that the user is authorized to access the requested customer databases.

The Hosted or OnSite server must also be able to communicate with any identity services required for authentication.

No Customers Appear

For Hosted deployments, an empty customer list may mean that the authenticated account has not been granted access to any customer databases.

For OnSite installations, the configured customer should normally be selected automatically because only one customer database is present.

Reporting Local Service Cannot Access SQL Server

SQL Server connectivity problems should be diagnosed according to the configured authentication model.

For SQL Server Authentication, the Reporting Local Service should normally use Local System, and administrators should verify that the configured SQL credentials remain valid.

For Windows Authentication, the service must use an authorized Windows user or service account. The account must be able to connect to SQL Server and must possess the required database permissions. The service should be restarted after the account is changed.

Unexpectedly Repeated Report Rows

If report results contain repeated rows, the template should be checked for the simultaneous inclusion of Consumables and Incidents.

A report should contain one of these categories, not both. Because a device can have multiple consumables and multiple incidents, combining the two can multiply rows.

Template Cannot Be Edited

A predefined template displaying a lock icon cannot be edited directly. The user should copy it and modify the resulting private template instead.

Another User Cannot See a Custom Template

In SiteAudit 8.5.0.0, this is expected behavior. Custom templates are private to their creator and cannot be shared directly with another user.

Information to Provide to Support

When a Web Reports problem cannot be resolved locally, providing complete information to support can significantly improve the troubleshooting process.

The guide recommends including:

• Whether the SiteAudit environment is Hosted or OnSite
• The Web Reports version displayed in About
• The URL being used
• The exact error message
• A screenshot of the problem
• Whether the issue affects one user or multiple users
• Whether the issue affects one customer or all customers
• For OnSite systems, the Windows service status and authentication method
• The approximate time when the problem occurred

Users should not provide passwords, SQL Server credentials, authentication tokens, or other sensitive information.

Providing deployment type, version, scope, timing, and exact error details gives support personnel the context needed to distinguish between installation, authentication, permissions, networking, database, and report-design problems.

Overall Significance of Web Reports

Web Reports represents a shift toward a more accessible and centralized reporting model within SiteAudit. Instead of making a desktop application the primary reporting interface, SiteAudit 8.5 enables authorized users to perform common reporting activities through a web browser.

For Hosted users, one of the most important capabilities is centralized access to multiple customer databases. An authorized user can potentially select several customers and run the same report across them, making Web Reports suitable for organizations responsible for managing or analyzing many customer environments.

For OnSite customers, the primary benefit is browser-based access to the local SiteAudit database without requiring SiteAudit Viewer or Control Panel on every reporting workstation. The tradeoff is that administrators must configure and maintain the necessary local infrastructure, including the Web Reports license, Reporting Local Service, .NET 10 Framework, SQL Server connectivity, HTTPS access, and network configuration.

The reporting workflow itself is template-driven. Users select the appropriate customer scope, choose fields from Inventory, Lifetime Counters, Consumables, or Incidents, save the report definition, and generate results. Templates can be reused and organized from the dashboard, while predefined templates can serve as starting points for customized reports.

The restriction against combining Consumables and Incidents is especially important because it directly affects the structure and usability of report results. Users designing templates need to understand the underlying relationship between device records and these one-to-many data categories. When reports are designed within that limitation, Web Reports can combine device identity, configuration, usage, supplies, and operational information in ways that support a wide range of fleet-reporting requirements.

The browser-based results provide an immediate way to inspect information, while CSV and XLSX export make the same data available for additional analysis, distribution, or integration into other workflows.

Security and access are also integral to the design. Microsoft Entra ID is used for authentication, and users remain limited to customer databases for which their accounts have been authorized. In OnSite environments, SQL Server permissions and the identity used by the Reporting Local Service add another layer of access control.

Administrators must pay particular attention to the authentication model used for SQL Server. SQL Server Authentication normally works with the Reporting Local Service running under Local System, whereas Windows Authentication requires a Windows account with the necessary SQL Server and database permissions. Correctly aligning the service configuration with the database authentication model is essential to reliable operation.

The use of HTTPS and port 2850 for OnSite deployments also means that Web Reports should be considered a network service rather than merely a locally installed application. Remote browser access depends on firewall rules, DNS resolution, server identity, and certificate trust. The troubleshooting guidance reflects this layered architecture by separating local application tests from remote network-access tests.

Finally, Web Reports changes which SiteAudit components need to be deployed to individual users. SiteAudit Viewer and Control Panel continue to provide functions outside the reporting scope, but users who only need to retrieve and export information may be able to perform their responsibilities entirely through the browser. This can simplify workstation configuration while allowing administrators to preserve tighter control over SiteAudit administration and monitoring functions.

In summary, SiteAudit 8.5 Web Reports provides a consolidated browser-based reporting system for both Hosted and OnSite environments. It supports reusable templates, multi-customer reporting in Hosted deployments, automatic single-customer selection in OnSite deployments, multiple categories of SiteAudit information, browser-based results, and CSV or XLSX export. Its architecture places particular importance on user authorization, SQL Server connectivity, service-account configuration, HTTPS networking, and thoughtful report design. When these elements are configured correctly, Web Reports provides users with direct access to SiteAudit reporting functionality without requiring the traditional desktop reporting applications on every workstation.