5-26TH07RFI - Attachment B - Technical Questionnaire Capability Responses - FINAL 12.22.2025.pdf

PDF 128 KB Posted

Attached to
RFI - Windows Device Management
Solicitation number
26TH07RFI
Issued by
Utah

About this file

This is a Technical Questionnaire and Capability Responses document for Jordan School District's RFI #26TH07RFI in Utah, seeking information on Windows Device Management solutions. The RFI requests detailed vendor responses across 14 capability areas designed to evaluate endpoint management platforms for approximately 3,500 Windows devices and 55 technicians managing approximately 11,000 total devices. Key capability areas include platform architecture and deployment, PXE-based provisioning and imaging workflows, device naming and domain join processes, identity and access security controls, software distribution and patch management, privilege management, inventory discovery, remote support, reporting and analytics, migration strategies, proof of concept approaches, server operating systems management, and integration capabilities with systems including Trend Micro, Google Admin Console, Skyward, Destiny Resource Manager, and on-premises Active Directory/LDAP. Vendors must explain how each capability is implemented, which products or modules are required, whether capabilities are core or add-on features, and any key limitations or tradeoffs.

The RFI emphasizes several critical requirements based on prior lessons learned and security assessments. Jordan School District is intentionally cautious about moving away from PXE-based provisioning workflows and requires detailed step-by-step explanations if vendors propose alternatives, including how baseline consistency is guaranteed, OEM variability is handled, device recovery and re-provisioning are performed, and what operational tradeoffs exist. The district requires role-based access control capabilities supporting approximately 55 technicians with four different job types, removal of persistent local administrator rights with just-in-time elevation support, and comprehensive reporting on large-scale software deployments with per-device visibility. The RFI also requests information on licensing structure applicability to the 3,500 Windows devices and 55 technicians, including how licensing is affected by device reimaging, replacement, or decommissioning, and recommended proof of concept approaches for an environment of this scale.

View the file

Other files

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

Jordan School District RFI # 26TH07RFI Attachment B

RFI # 26TH07RFI

Attachment B

Technical Questionnaire & Capability Responses

(This document to be submitted with RFI response.)

Please read all instructions below to ensure all required documentation is submitted with your response.

The capability areas listed below reflect JSD’s current needs and desired outcomes, based on existing workflows and lessons learned from the current endpoint management platform.

Vendors should use this questionnaire to explain how their platform fulfills each capability area, including:

• How the capability is implemented.

• Which product(s), module(s), or edition(s) are required.

• Whether the capability is core or requires add-ons.

• Key limitations, tradeoffs, or assumptions.

A. ARCHITECTURE & DEPLOYMENT

Describe the overall platform architecture and agent model.

Describe how devices communicate when off-network.

Describe support for centralized infrastructure with optional local caching or distribution nodes.

B. PROVISIONING, IMAGING & BASELINE CONTROL

Describe PXE-based provisioning workflows.

JSD is intentionally cautious about moving away from PXE-based workflows.

Alternatives to PXE may be considered only if they provide equivalent or greater levels of:

• Consistency and determinism.

• Recovery and reimage capability.

• Operational transparency and control.

If proposing a non-PXE workflow, provide a step-by-step explanation of how baseline consistency, recovery, and reimaging are achieved. If a vendor proposes a workflow that does not rely on PXE, provide very detailed, step-by-step explanations covering:

• How a consistent baseline is guaranteed without PXE.

• How OEM variability and preinstalled software are handled.

• How full device recovery and re-provisioning are performed.

• What operational tradeoffs or limitations exist compared to PXE-based imaging.

C. DEVICE NAMING, DOMAIN JOIN & IDENTITY HEALTH

Describe device naming workflows and integration with asset tags and location-based naming.

Describe how domain join is performed and how join failures or broken trust relationships are detected, reported, and remediated.

D. IDENTITY, ACCESS & SECURITY

This section is intended to understand least-privilege design, particularly around service accounts, based on findings from prior security assessments.

Describe all service accounts required by the platform, including purpose and privilege scope.

Describe how service account permissions can be reduced, scoped, and audited.

Describe RBAC capabilities for technicians, including:

• Scope by site or location.

• Restrictions on actions (view, deploy, remediate).

• Support for approximately 55 technicians managing approximately 11,000 devices with 4 different job types.

E. SOFTWARE DISTRIBUTION & PATCH MANAGEMENT

Describe Windows OS patch management workflows, including scheduling, reboot control, and compliance reporting.

Describe third-party application patching (e.g., Chrome, Adobe).

Describe lifecycle management for custom or unknown applications, such as content filtering/classroom management monitoring software.

Describe execution reporting for large-scale deployments, including per-device success/failure visibility.

Describe how you push multiple software package types (.exe, .msi, .bat, .msix).

Describe how/if you can do installations via the Windows app store.

F. PRIVILEGE MANAGEMENT

Describe the removal of persistent local administrator rights and support for just-in-time elevation.

Describe auditing and user experience for privilege elevation workflows.

G. INVENTORY, DISCOVERY & UNMANAGED DEVICES

Describe hardware and software inventory capabilities.

Describe unmanaged device discovery and missing-agent detection.

H. REMOTE SUPPORT & TROUBLESHOOTING

Describe remote control and troubleshooting capabilities for on- and off-network devices.

I. REPORTING, ANALYTICS & EXECUTIVE VISIBILITY

Describe operational and executive-level dashboards, trend analysis, and reporting/export options.

J. MIGRATION STRATEGY

Describe migration from an existing endpoint management platform, including coexistence, conflict avoidance, and rollback strategies.

K. PROOF OF CONCEPT (POC) APPROACH

Describe your recommended POC approach for an environment of this size, including duration, scope, success criteria, and required resources.

L. SERVER OPERATING SYSTEMS (SEPARATE CONSIDERATION)

Describe Windows and Linux server management capabilities and how they differ from workstation management.

M. LICENSING & COMMERCIAL MODEL

Describe licensing structure (per device, per user, per technician, or hybrid).

Describe how licensing applies to approximately 3,500 Windows devices and 55 technicians.

Describe how licensing is affected by device reimaging, replacement, or decommissioning.

N. INTEGRATIONS (INFORMATIONAL)

Describe integration with the following:

• Trend Micro

• Google Admin Console

• Skyward

• Destiny Resource Manager

• On-prem AD/LDAP

A. ARCHITECTURE & DEPLOYMENT
B. PROVISIONING, IMAGING & BASELINE CONTROL
C. DEVICE NAMING, DOMAIN JOIN & IDENTITY HEALTH
D. IDENTITY, ACCESS & SECURITY
E. SOFTWARE DISTRIBUTION & PATCH MANAGEMENT
F. PRIVILEGE MANAGEMENT
G. INVENTORY, DISCOVERY & UNMANAGED DEVICES
H. REMOTE SUPPORT & TROUBLESHOOTING
I. REPORTING, ANALYTICS & EXECUTIVE VISIBILITY
J. MIGRATION STRATEGY
K. PROOF OF CONCEPT (POC) APPROACH
L. SERVER OPERATING SYSTEMS (SEPARATE CONSIDERATION)
M. LICENSING & COMMERCIAL MODEL
N. INTEGRATIONS (INFORMATIONAL)

File details come from the government source that posted it. Updated .