3-26TH07RFI Windows Device Management - FINAL 12.22.25.pdf

REQUEST FOR INFORMATION

WINDOWS DEVICE MANAGEMENT

SOLICITATION # 26TH07RFI

RESPONSE DUE

FRIDAY, JANUARY 30, 2026

2:00 p.m. MST

QUESTIONS DUE

TUESDAY, JANUARY 20, 2026

12:00 p.m. MST

Jordan School District Purchasing Department

Senior Buyer: Tonya Hodges, NIGP-CPP, CPPB 7905 South Redwood Road

West Jordan, Utah 84088-4601

Jordan School District RFI # 26TH07RFI Windows Device Management

CONTENTS

PART 1: OVERVIEW AND NOTICES

1. PURPOSE OF REQUEST FOR INFORMATION (RFI)

2. NOTICES

3. QUESTION AND ANSWER PERIOD

4. SUBMIT VIA U3P BONFIRE

5. PROTECTED INFORMATION

A. PROCESS FOR REQUESTING NONDISCLOSURE

B. REDACTED COPY

PART 2: SCOPE OF WORK AND REQUESTED INFORMATION

1. RFI INTENT

2. RESPONSE GUIDANCE

3. BACKGROUND AND ENVIRONMENT OVERVIEW

A. CURRENT DEVICE PROCUREMENT AND PROVISIONING WORKFLOW

B. INITIAL DEVICE HANDLING

C. IMAGING, PXE, AND BASELINE CONTROL

D. DEVICE NAMING, DOMAIN JOIN, AND IDENTITY

E. ARCHITECTURE AND LOCAL INFRASTRUCTURE

F. POST-IMAGING LIFECYCLE

G. COMPARISON TO APPLE/GOOGLE AUTOMATED ENROLLMENT MODELS

4. RFI RESPONSE MATERIALS

A. ATTACHMENT A: VENDOR DIFFERENTIATING CAPABILITIES

B. ATTACHMENT B: TECHNICAL QUESTIONNAIRE AND CAPABILITY RESPONSES

C. ATTACHMENT C: PRODUCT IDENTIFICATION AND LICENSING MAPPING

D. ATTACHMENT D: CLAIM OF BUSINESS CONFIDENTIALITY (IF APPLICABLE)

PART 3: RFI EVALUATION

REQUEST FOR INFORMATION

WINDOWS DEVICE MANAGEMENT

SOLICITATION # 26TH07RFI

This Request for Information (RFI), having been determined to be the appropriate method for gathering information for Jordan School District (JSD), is designed to provide interested vendors with sufficient information to submit responses to this RFI meeting the intent of the request. It is not intended to limit a vendor’s content or exclude any relevant or essential data.

This RFI is issued in accordance with State of Utah Procurement Code, Utah Code Annotated (UCA) Chapter 63G-6a, and applicable Rules found in the Utah Administrative Rule (UAR). If any provision of this RFI conflicts with the UCA or UAR, the UCA or UAR will take precedence.

PART 1: OVERVIEW AND NOTICES

The reference number for this RFI is 26TH070RFI. This number should be referred to on all responses, correspondence, and documentation relating to this RFI.

1. PURPOSE OF REQUEST FOR INFORMATION (RFI)

The JSD Information Systems (IT) department is seeking information on solutions for Windows Device Management.

This RFI is intentionally structured differently from a traditional checkbox-driven or compliance-only RFI.

The evaluation team has decades of experience reviewing vendor responses and recognizes that many RFIs result in copy-and-paste marketing language, generic product descriptions, or large addenda of datasheets that do not directly answer the questions being asked. That is not the objective of this RFI.

The intent of this RFI is to create an opportunity for vendors to help Jordan School District truly understand, in technical and operational detail, how their platform works in practice — including architecture, workflows, dependencies, tradeoffs, and limitations.

Vendors are encouraged to:

• Treat this as a technical conversation, not a marketing exercise.

• Explain how capabilities are implemented, not just that they exist.

• Clearly identify where functionality is core vs. add-on vs. separate product.

• Be transparent about assumptions, prerequisites, and areas of partial support.

JSD has deliberately structured this RFI to make it easy to respond to directly, with guided sections and clear context about current workflows and constraints. In return, vendors are asked to:

• Provide clear, concise, and well-structured answers.

• Avoid excessive attachments or datasheet dumps.

• Make responses easy to read and easy to map to the questions asked.

Responses that prioritize clarity, technical depth, and honesty will be more valuable to the evaluation process than responses that prioritize breadth or marketing language.

Based on RFI responses, JSD may:

• Invite select vendors to participate in a proof of concept (POC).

• Issue a subsequent RFP with defined technical minimums.

• Select a preferred solution and conduct a subsequent pricing-only solicitation.

2. NOTICES

An RFI is a request for information only. An RFI is not a solicitation for quotations, bids, or proposals. Vendors should not include pricing information in RFI responses. An RFI is not a procurement process and may not be used to enter into a contract or to make a purchase.

Information submitted in response to this RFI may be used to develop a subsequent solicitation. Failure to respond to this RFI will not disqualify any vendor from participation in a subsequent solicitation.

All costs associated with preparing and responding to this RFI are the sole responsibility of the responding vendor and will not be reimbursed by JSD. All materials submitted in response to this RFI will become the property of JSD.

JSD reserves the right to cancel this RFI at any time.

3. QUESTION AND ANSWER PERIOD

All questions should be submitted through Utah Public Procurement Place Bonfire (U3P Bonfire) at https://utah.bonfirehub.com during the designated time for questions (Q&A period) listed on U3P Bonfire. Questions submitted through any other channel will not be answered. Questions may be answered in the order that they are submitted or may be compiled into one document and answered via an addendum after the Q&A period has ended.

Answers disseminated by JSD through U3P Bonfire via Q&A or via Public Notice will constitute an addendum to this RFI. Addenda may modify the scope of this RFI. Vendors should periodically check U3P Bonfire for answered questions and addenda before the due date.

4. SUBMIT VIA U3P BONFIRE

RFI responses must be submitted digitally via U3P Bonfire at https://utah.bonfirehub.com by the deadline posted on U3P Bonfire. Late submissions will not be accepted.

When submitting an RFI response, allow sufficient time to complete the online forms and to upload documents. The RFI will end at the deadline. If a vendor is in the middle of uploading materials when the deadline arrives, the system will stop the upload process and the response will not be accepted by U3P Bonfire.

5. PROTECTED INFORMATION

The Government Records Access and Management Act (GRAMA), UCA 63G-2-305, provides in part that:

https://utah.bonfirehub.com/ https://utah.bonfirehub.com/ the following records are protected if properly classified by a governmental entity:

(1) trade secrets as defined in Section 13-24-2 [Uniform Trade Secrets Act] if the person submitting the trade secret has provided the governmental entity with the information specified in Section 63G-2-309 [Confidentiality Claims];

(2) commercial information or nonindividual financial information obtained from a person if:

(a) disclosure of the information could reasonably be expected to result in unfair competitive injury to the person submitting the information or would impair the ability of the governmental entity to obtain necessary information in the future;

(b) the person submitting the information has a greater interest in prohibiting access than the public in obtaining access; and

(c) the person submitting the information has provided the governmental entity with the information specified in 63G-2-309 [Confidentiality Claims];

(7) information submitted to or by a governmental entity in response to a request for information, except, subject to Subsections (1) and (2), that this Subsection (7) does not restrict the right of a person to have access to the information, after:

(a) a contract directly relating to the subject of the request for information has been awarded and signed by all parties; or

(b)

(i) a final determination is made not to enter into a contract that relates to the subject of the request for information; and

(ii) at least two years have passed after the day on which the request for information is issued;

A. PROCESS FOR REQUESTING NONDISCLOSURE

Any vendor requesting that a record be protected shall complete and include with the RFI response a Claim of Business Confidentiality Form (see Attachment D), including a concise statement of reasons supporting the claim of business confidentiality (UCA 63G-2- 309[1]) and a redacted copy of their RFI response clearly marked “Redacted Version.”

Vendor acknowledges that notations in the header, footer, or watermark of the RFI response will not be considered sufficient to constitute a request for nondisclosure of protected/proprietary information.

B. REDACTED COPY

If a vendor submits a response that contains information claimed to be business confidential or protected information, the vendor should submit one electronic redacted copy of the RFI response for public release, with all protected business confidential information either blacked-out or removed, clearly marked as “Redacted Version.”

Vendor acknowledges that their RFI response or redacted copy will be made public upon JSD’s receipt of a GRAMA request. Vendor will not be notified of any GRAMA request made to JSD for the vendor’s RFI response. If the vendor submits a redacted copy, then JSD will respond to a GRAMA request for vendor’s RFI response with the redacted copy. However, if a vendor fails to submit a redacted copy, then JSD will respond to a GRAMA request with the vendor’s RFI response, which will result in the vendor’s protected/proprietary information, if any, being made public.

PART 2: SCOPE OF WORK AND REQUESTED INFORMATION

1. RFI INTENT

The Information Systems (IT) department is seeking information on solutions for Windows Device Management. Information gathered through this RFI is intended to help JSD:

• Understand how vendors implement endpoint management capabilities, not merely whether features exist.

• Identify architectural dependencies, limitations, and operational considerations.

Based on RFI responses, JSD may:

• Invite select vendors to participate in a POC.

• Issue a subsequent RFP with defined technical minimums.

• Select a preferred solution and conduct a subsequent pricing-only solicitation.

2. RESPONSE GUIDANCE

In compiling the RFI response, vendors should:

• Answer questions as written.

• Avoid marketing brochures, datasheet dumps, or generic product descriptions.

• Clearly indicate native vs. add-on vs. third-party vs. open-source functionality.

• Clearly identify product names, editions, SKUs, or modules required.

Vendors are provided with dedicated sections to explain differentiating capabilities and partial support.

Do not include pricing quotes.

3. BACKGROUND AND ENVIRONMENT OVERVIEW

The following context is provided to assist vendors in understanding the operational environment and current workflows. This information is intended to explain why certain questions are being asked and to help vendors frame answers appropriately.

A. CURRENT DEVICE PROCUREMENT AND PROVISIONING WORKFLOW

Endpoint devices are procured based primarily on price and availability, resulting in purchases from multiple vendors that may change frequently (monthly or more often).

Because of this variability, vendor-based pre-staging, factory enrollment, or vendor-managed zero-touch provisioning models (e.g., OEM enrollment or vendor ZTNA pre-registration) have not been operationally viable.

B. INITIAL DEVICE HANDLING

All Windows devices are received and handled on-site by IT staff prior to assignment to end users. Upon receipt, devices are unboxed, physically asset-tagged, and prepared for imaging and provisioning by IT.

C. IMAGING, PXE, AND BASELINE CONTROL

Devices are typically booted into PXE mode and imaged from an on-premises imaging server using a standardized golden image.

PXE-based imaging is a deliberate and valued part of the current workflow, and has proven to be reliable, repeatable, and operationally efficient at scale. PXE-based imaging is used to:

• Establish a known and repeatable baseline.

• Remove OEM-installed software and bloatware.

• Apply deterministic device naming and base configuration.

• Ensure devices are in a controlled state before any user interaction.

• Ensure appropriate tools, such as anti-virus, are installed before deployment.

D. DEVICE NAMING, DOMAIN JOIN, AND IDENTITY

Device naming conventions incorporate asset tag and physical location.

Devices are joined to the on-premises Active Directory domain as part of provisioning.

E. ARCHITECTURE AND LOCAL INFRASTRUCTURE

Core endpoint management infrastructure is typically centralized.

Secondary schools host local servers or caching nodes to improve performance for imaging, software distribution, or patching.

F. POST-IMAGING LIFECYCLE

After provisioning, devices may operate either on the internal network, or Internet-only once deployed to users.

JSD is actively working toward:

• Reducing or eliminating persistent local administrator rights for end users.

• Increasing visibility, reporting, and accountability for patching and remediation actions.

G. COMPARISON TO APPLE/GOOGLE AUTOMATED ENROLLMENT MODELS

JSD has experience with Apple/Google automated enrollment workflows where devices are associated with the organization by serial number and automatically present enrollment options at first Internet connection.

We have been unable to translate this approach to Windows Devices due to:

• Multi-vendor procurement.

• Inconsistent factory OS versions.

• OEM-installed software variability.

• Lack of a single, enforced Windows cloud baseline.

Vendors should consider this context when describing provisioning, enrollment, and recovery workflows.

We run local on-premise active directory and are several years away from Entrata or Azure Domain services, so systems that rely on this infrastructure will likely not meet our needs.

4. RFI RESPONSE MATERIALS

Vendors that are interested in responding to this RFI should submit the following:

A. ATTACHMENT A: VENDOR DIFFERENTIATING CAPABILITIES

This section is the vendor’s opportunity to clearly and concisely explain why your solution stands out and why it should be seriously considered for further evaluation.

This is not a requirement to cover every feature. It is an opportunity to make a compelling technical case for your solution in a way that is easy to digest for evaluators.

Responses that are thoughtful, specific, and grounded in operational reality will be more impactful than broad or overly polished marketing statements.

Responses should be one (1) page maximum.

B. ATTACHMENT B: TECHNICAL QUESTIONNAIRE AND CAPABILITY RESPONSES

Vendors are asked to provide detailed narratives on the following:

• Architecture and Deployment

• Device Naming, Domain Join, and Identity Health

• Identity, Access, and Security

• Software Distribution and Patch Management

• Privilege Management

• Inventory, Discovery, and Unmanaged Devices

• Remote Support and Troubleshooting

• Reporting, Analytics, and Executive Visibility

• Migration Strategy

• Proof of Concept (POC) Approach

• Server Operating Systems (Separate Consideration)

• Licensing and Commercial Model

• Integrations (Informational)

C. ATTACHMENT C: PRODUCT IDENTIFICATION AND LICENSING MAPPING

List all products, modules, or SKUs required to meet RFI capabilities in the following Capability Areas:

• Core Management

• Patch Management

• Privilege Management

• Imaging/Recovery

• Reporting/Dashboards

D. ATTACHMENT D: CLAIM OF BUSINESS CONFIDENTIALITY (IF APPLICABLE)

If applicable, submit a Claim of Business Confidentiality Form (Attachment D) and a redacted copy of the RFI response.

PART 3: RFI EVALUATION

All RFI responses properly submitted will be accepted by JSD.

RFI responses will be evaluated by a JSD evaluation committee. Materials may be evaluated by anyone designated by JSD as part of the evaluation committee.

Information submitted in response to this RFI may be used to:

• Invite select vendors to participate in a proof of concept (POC).

• Issue a subsequent RFP with defined technical minimums.

• Select a preferred solution and conduct a subsequent pricing-only solicitation.

[The end.]

PART 3: RFI EVALUATION