Fix Apostrophe

elliot-huffman · elliot-huffman · commit ae9360e91ca5 · 2025-09-11T22:59:22.000-04:00
Replaced stylized apostrophe with standard one.
diff --git a/docs/Data-Gateway/Reference/index.md b/docs/Data-Gateway/Reference/index.md
@@ -27,7 +27,7 @@ All requests must include a valid **OAuth 2.0 access token** in the `Authorizati
 
 ### Steps
 
-1. Sign in with your organization’s Entra ID account to obtain an access token for the Data Gateway application.  
+1. Sign in with your organization's Entra ID account to obtain an access token for the Data Gateway application.  
 2. Include the token in each API request:
 
 ```bash
diff --git a/docs/Data-Gateway/index.md b/docs/Data-Gateway/index.md
@@ -1,6 +1,6 @@
 # SHI - Data Gateway
 
-Data Gateway is SHI’s secure data layer that unifies access to product and tenant information across SHI solutions.  
+Data Gateway is SHI's secure data layer that unifies access to product and tenant information across SHI solutions.  
 It provides a single, trusted path for ingesting, storing, and retrieving the data that powers SHIELD and related services.
 
 !!! tip "Who should read this?"
@@ -13,8 +13,8 @@ It provides a single, trusted path for ingesting, storing, and retrieving the da
 Data Gateway helps you:
 
 - **Use the web UI** to explore tenant data and SHI experiences such as **Tenant Manager** and **LicenseGPT**.
-- **Integrate via API** with SHI’s services using the public OpenAPI/Swagger specification.
-- **Authenticate securely** with your organization’s Entra ID account to protect data access.
+- **Integrate via API** with SHI's services using the public OpenAPI/Swagger specification.
+- **Authenticate securely** with your organization's Entra ID account to protect data access.
 - **Ingest and retrieve reports** including license reports, entitlement data, and telemetry.
 - **Manage updates** such as update packages and configuration channels stored in Azure Blob Storage.
 - **Access processed relational data** in Azure SQL for compliance and reporting scenarios.
diff --git a/docs/SHIELD/Defend/Deployment.md b/docs/SHIELD/Defend/Deployment.md
@@ -1,6 +1,6 @@
 # Deployment
 
-The Defend module is deployed automatically as part of the SHIELD platform’s **Core Infrastructure deployment** process. It does not require any separate deployment scripts or packages.
+The Defend module is deployed automatically as part of the SHIELD platform's **Core Infrastructure deployment** process. It does not require any separate deployment scripts or packages.
 
 This page clarifies when and how Defend becomes active, and what its dependencies are.
 
@@ -56,4 +56,4 @@ To use Defend, the following must already be deployed:
 - [Defend Usage Guide](Usage-Guide/index.md)
 - [Defend Reference](Reference/index.md)
 - [Troubleshooting](Troubleshooting.md)
-- [SHIELD Platform Deployment](../Getting-Started.md)
+- [SHIELD Platform Deployment](../Getting-Started.md)
diff --git a/docs/SHIELD/Defend/Prerequisites.md b/docs/SHIELD/Defend/Prerequisites.md
@@ -21,7 +21,7 @@ The Defend module relies on infrastructure that must be deployed via the Deploy
 
 ## Role-Based Permissions
 
-To use Defend’s lifecycle functionality, the signed-in admin must have the following roles in Entra ID:
+To use Defend's lifecycle functionality, the signed-in admin must have the following roles in Entra ID:
 
 | Role | Reason |
 |------|--------|
@@ -63,4 +63,3 @@ To verify:
 - [Defend Usage Guide](Usage-Guide/index.md)
 - [Hardware Requirements](Reference/index.md)
 - [SHIELD Prerequisites](../Prerequisites/index.md)
-
diff --git a/docs/SHIELD/Defend/Reference/index.md b/docs/SHIELD/Defend/Reference/index.md
@@ -25,7 +25,7 @@ SHIELD enforces hardware baselines per security class, especially for **Privileg
 | Graphics Support  | NVIDIA recommended (avoid AMD graphics)     |
 
 !!! info "Device Security Considerations"
-    In ESM/SSM, hardware risks are lower, but it’s still important to avoid unsupported OEMs and poor firmware hygiene. These devices typically handle non-elevated tasks.
+    In ESM/SSM, hardware risks are lower, but it's still important to avoid unsupported OEMs and poor firmware hygiene. These devices typically handle non-elevated tasks.
 
 ### Privileged Mode (PSM)
 
@@ -49,25 +49,31 @@ Each SHIELD lifecycle action is mapped to a standardized backend workflow. The f
 ### Device Workflow Diagrams
 
 #### Commission Device
+
 📊 [Device - Commission](./Diagrams/Device-Commission.md)
 
 #### Decommission Device
+
 📊 [Device - Decommission](./Diagrams/Device-Decommission.md)
 
 #### Assign User to Device
+
 📊 [Device - Assign](./Diagrams/Device-Assign.md)
 
 #### Unassign User from Device
+
 📊 [Device - Unassign](./Diagrams/Device-Unassign.md)
 
 ---
 
 ### User Workflow Diagrams
 
 #### Commission User
+
 📊 [User - Commission](./Diagrams/User-Commission.md)
 
 #### Decommission User
+
 📊 [User - Decommission](./Diagrams/User-Decommission.md)
 
 ---
@@ -85,4 +91,3 @@ A dedicated section for advanced Privileged workflows, including intermediary lo
 - [Defend Usage Guide](../Usage-Guide/index.md)
 - [Device Lifecycle](../Usage-Guide/Device/0-Commission.md)
 - [User Lifecycle](../Usage-Guide/User/Commission.md)
-
diff --git a/docs/SHIELD/Defend/Troubleshooting.md b/docs/SHIELD/Defend/Troubleshooting.md
@@ -1,16 +1,18 @@
 # Troubleshooting
 
-This section addresses common issues encountered when using the Defend module’s lifecycle management features. It also offers clarification on edge cases, expected behaviors, and safe recovery actions.
+This section addresses common issues encountered when using the Defend module's lifecycle management features. It also offers clarification on edge cases, expected behaviors, and safe recovery actions.
 
 ---
 
 ## Issue: Devices not appearing in SHIELD UI
 
 **Cause:**
+
 - Devices are not hybrid-joined or cloud-joined to Entra ID
 - Devices are not enrolled or synced into Intune
 
 **Resolution:**
+
 - Confirm the device is joined to Entra ID
 - Ensure it is visible in the Intune portal ([https://intune.microsoft.com](https://intune.microsoft.com))
 - Ensure it is not already managed by another tenant or stale registration
@@ -20,11 +22,13 @@ This section addresses common issues encountered when using the Defend module’
 ## Issue: Users not showing up when trying to commission
 
 **Cause:**
+
 - The user has already been onboarded
 - The user is filtered out by Entra ID query
 - Admin does not have required permissions
 
 **Resolution:**
+
 - Verify the user exists in Entra ID
 - Confirm you're operating with Global Reader or User Administrator role
 - Switch to a different security class to check other eligible users
@@ -34,11 +38,13 @@ This section addresses common issues encountered when using the Defend module’
 ## Issue: Lifecycle actions failing silently or UI not responding
 
 **Cause:**
+
 - Required Defender for Endpoint workspace is not initialized
 - Scoped Intune tags are missing
 - Conditional Access policies are not yet deployed
 
 **Resolution:**
+
 - Follow workspace setup verification steps in the [Usage Guide](Usage-Guide/index.md), under **Defender for Endpoint Workspace Creation**
 - Check that SHIELD infrastructure was successfully deployed from the Deploy module
 - Review prerequisites in [Defend Prerequisites](Prerequisites.md)
@@ -48,10 +54,12 @@ This section addresses common issues encountered when using the Defend module’
 ## Issue: Privileged device wipe triggered unexpectedly
 
 **Cause:**
+
 - Privileged commissioning/unassignment flow triggered without assigned users
 - Attempted to assign a new user without retaining previous assignment
 
 **Resolution:**
+
 - Always include current assigned users in the assignment flow
 - Ensure wipe behavior for privileged devices is clearly understood (see the [Usage Guide](Usage-Guide/index.md))
 
@@ -60,10 +68,12 @@ This section addresses common issues encountered when using the Defend module’
 ## Issue: Temporary credentials not saved after privileged user creation
 
 **Cause:**
+
 - Admin did not record credentials from the popup
 - UI was closed or refreshed before saving
 
 **Resolution:**
+
 - Re-run commissioning with a new user
 - Contact SHI if lifecycle audit recovery is needed
 
@@ -72,12 +82,15 @@ This section addresses common issues encountered when using the Defend module’
 ## FAQs
 
 ### Are lifecycle actions idempotent?
+
 Yes. If a device or user is already managed, SHIELD will not reapply the same configuration unless it detects a mismatch.
 
 ### Can I reverse a decommission action?
+
 No. Once a user or device is removed, it must be re-commissioned.
 
 ### Does the UI prevent mistakes?
+
 Yes — warnings and confirmations are built into the UI. However, wipe actions for privileged devices occur automatically in certain workflows.
 
 ---
@@ -87,4 +100,3 @@ Yes — warnings and confirmations are built into the UI. However, wipe actions
 - [Defend Usage Guide](Usage-Guide/index.md)
 - [Defend Reference](Reference/index.md)
 - [Defend Prerequisites](Prerequisites.md)
-
diff --git a/docs/SHIELD/Defend/Usage-Guide/index.md b/docs/SHIELD/Defend/Usage-Guide/index.md
@@ -13,7 +13,7 @@ Lifecycle Management is triggered from within the SHIELD web interface and allow
 - Enforce metadata tagging and Intune integration
 - Apply group policies and conditional access boundaries
 
-All actions are class-aware and scoped by SHIELD’s infrastructure.
+All actions are class-aware and scoped by SHIELD's infrastructure.
 
 ---
 
@@ -29,6 +29,7 @@ Commissioning a device registers it with SHIELD and assigns lifecycle metadata.
 📊 [Workflow Diagram](../Reference/Diagrams/Device-Commission.md)
 
 #### UI Example
+
 .
 ![Select Device - Light](../../../assets/Images/Screenshots/Select-Unmanaged-Device-Light.png#only-light){ loading=lazy width="300" }
 ![Select Device - Dark](../../../assets/Images/Screenshots/Select-Unmanaged-Device-Dark.png#only-dark){ loading=lazy width="300" }
@@ -40,7 +41,7 @@ Commissioning a device registers it with SHIELD and assigns lifecycle metadata.
 
 ### Decommission a Device
 
-Removes a device from SHIELD’s lifecycle system.
+Removes a device from SHIELD's lifecycle system.
 
 📖 [Decommission a Device](./Device/1-Decommission.md)  
 📊 [Workflow Diagram](../Reference/Diagrams/Device-Decommission.md)
@@ -58,7 +59,7 @@ Assigns one or more users to a privileged device (PAW). All others will be denie
 
 ### Unassign a User from a PAW
 
-Removes a user’s access from a PAW. If no users remain, a wipe is issued.
+Removes a user's access from a PAW. If no users remain, a wipe is issued.
 
 📖 [Unassign User](./Device/3-Unassign.md)  
 📊 [Workflow Diagram](../Reference/Diagrams/Device-Unassign.md)
@@ -99,7 +100,7 @@ Privileged users are deleted from Entra ID. Non-privileged users are simply remo
 
 ## Security Classes
 
-All operations respect SHIELD’s class-based enforcement:
+All operations respect SHIELD's class-based enforcement:
 
 - **Enterprise**: standard users/devices with baseline protections
 - **Specialized**: enhanced controls and policy targeting
@@ -118,4 +119,4 @@ Class is selected at the top of the UI before performing lifecycle actions.
 - [Device Commissioning](./Device/0-Commission.md)
 - [User Commissioning](./User/Commission.md)
 - [Reference Diagrams](../Reference/index.md)
-- [Hardware Requirements](../Reference/Hardware-Selection.md)
+- [Hardware Requirements](../Reference/Hardware-Selection.md)
diff --git a/docs/SHIELD/Defend/index.md b/docs/SHIELD/Defend/index.md
@@ -13,19 +13,19 @@ Whereas the Deploy module provisions the infrastructure, **Defend is responsible
 - Automatic Intune and Entra ID tagging
 - Lifecycle management rules based on selected security class
 
-All these actions are exposed via the SHIELD Lifecycle UI and the platform’s API endpoints.
+All these actions are exposed via the SHIELD Lifecycle UI and the platform's API endpoints.
 
 ---
 
 ## Security Class Enforcement
 
-Defend strictly applies the lifecycle rules associated with each of SHIELD’s supported security classes:
+Defend strictly applies the lifecycle rules associated with each of SHIELD's supported security classes:
 
 - **Enterprise (ESM)** – standard business users and workstations
 - **Specialized (SSM)** – elevated or regulated roles and systems
 - **Privileged (PSM)** – most secure tier, requires clean hardware, wipes on commission/unassign, and restricted access boundaries
 
-The class is selected in the UI prior to performing any lifecycle action. 
+The class is selected in the UI prior to performing any lifecycle action.
 
 ---
 
@@ -47,4 +47,3 @@ The lifecycle engine handles all object mapping, Intune tagging, group membershi
 - [Usage Guide](Usage-Guide/index.md)
 - [Reference](Reference/index.md)
 - [Troubleshooting](Troubleshooting.md)
-
diff --git a/docs/SHIELD/Deploy/Deployment/index.md b/docs/SHIELD/Deploy/Deployment/index.md
@@ -1,6 +1,6 @@
 # Deployment
 
-The Deploy module is provisioned automatically as part of the SHIELD platform’s Core Infrastructure deployment. This page provides clarity on how the Deploy module fits into the broader deployment flow and what is delivered specifically by this module.
+The Deploy module is provisioned automatically as part of the SHIELD platform's Core Infrastructure deployment. This page provides clarity on how the Deploy module fits into the broader deployment flow and what is delivered specifically by this module.
 
 ---
 
@@ -14,7 +14,7 @@ There is no separate installation or deployment process specific to the Deploy m
 
 ## What Is Deployed?
 
-The Deploy module provisions all foundational objects required for SHIELD’s lifecycle and security logic:
+The Deploy module provisions all foundational objects required for SHIELD's lifecycle and security logic:
 
 - Security groups for each SPA tier (Enterprise, Specialized, Privileged)
 - Intune Scope Tags for device policy enforcement
@@ -40,7 +40,7 @@ From the home screen:
 3. Check the agreement box
 4. Click **Deploy Infrastructure**
 
-You’ll then see:
+You'll then see:
 
 - A progress spinner
 - Automatic status updates
@@ -75,4 +75,3 @@ These cannot be renamed or deleted through the SHIELD UI.
 - [Reference Docs](../Reference/index.md)
 - [Troubleshooting](../Troubleshooting.md)
 - [Full SHIELD Deployment](../../Getting-Started.md)
-
diff --git a/docs/SHIELD/Deploy/Reference/index.md b/docs/SHIELD/Deploy/Reference/index.md
@@ -1,6 +1,6 @@
 # Reference
 
-This reference section provides technical specifications and supporting details for SHIELD’s Deploy module, including identity protection policies and configuration recommendations that align with the SPA architecture.
+This reference section provides technical specifications and supporting details for SHIELD's Deploy module, including identity protection policies and configuration recommendations that align with the SPA architecture.
 
 ---
 
@@ -14,7 +14,7 @@ These policies are designed to:
 - Block access to privileged resources if risk conditions are met
 - Route access through compliant devices and monitored interfaces
 
-This aligns with Microsoft’s Zero Trust security model and helps enforce separation between administrative and user environments.
+This aligns with Microsoft's Zero Trust security model and helps enforce separation between administrative and user environments.
 
 ---
 
diff --git a/docs/SHIELD/Deploy/index.md b/docs/SHIELD/Deploy/index.md
@@ -1,16 +1,16 @@
 # Overview
 
-SHIELD’s Deploy module provides the foundation for a secure environment using Microsoft’s **Securing Privileged Access (SPA)** architecture. This module automates the provisioning of security-critical components such as identity boundaries, privileged access zones, Conditional Access policies, and more.
+SHIELD's Deploy module provides the foundation for a secure environment using Microsoft's **Securing Privileged Access (SPA)** architecture. This module automates the provisioning of security-critical components such as identity boundaries, privileged access zones, Conditional Access policies, and more.
 
-The Deploy module ensures your environment is segmented appropriately and aligns with Microsoft’s Zero Trust principles by separating enterprise and privileged systems.
+The Deploy module ensures your environment is segmented appropriately and aligns with Microsoft's Zero Trust principles by separating enterprise and privileged systems.
 
 ---
 
 ## What Is SPA?
 
-Microsoft’s **Securing Privileged Access (SPA)** model is a layered defense framework designed to protect your most critical systems from identity compromise. SPA separates access tiers between everyday business operations and sensitive administrative functions.
+Microsoft's **Securing Privileged Access (SPA)** model is a layered defense framework designed to protect your most critical systems from identity compromise. SPA separates access tiers between everyday business operations and sensitive administrative functions.
 
-The diagram below illustrates SPA’s architecture and how privileged vs enterprise identity flows interact with the environment.
+The diagram below illustrates SPA's architecture and how privileged vs enterprise identity flows interact with the environment.
 
 ```mermaid
 flowchart LR
@@ -80,4 +80,3 @@ By centralizing and automating the deployment of SPA, the Deploy module:
 - [Deploy Usage Guide](Usage-Guide.md)
 - [Deploy Reference](Reference/index.md)
 - [Troubleshooting Deploy Module](Troubleshooting.md)
-
diff --git a/docs/SHIELD/Discover/index.md b/docs/SHIELD/Discover/index.md
@@ -32,7 +32,7 @@ The Discover module is built on a modular architecture that emphasizes extensibi
 
 ### Plugin
 
-Discover’s core engine is extensible through plugins. Each plugin is responsible for extracting and evaluating configuration from a specific service, for example:
+Discover's core engine is extensible through plugins. Each plugin is responsible for extracting and evaluating configuration from a specific service, for example:
 
 - 🔌 **Entra ID Plugin** – Retrieves directory and user-level settings
 - 🔌 **Defender for Endpoint Plugin** – Retrieves licensing status
diff --git a/docs/SHIELD/Prerequisites/index.md b/docs/SHIELD/Prerequisites/index.md
@@ -18,7 +18,7 @@ SHIELD automates secure deployment and lifecycle management using Microsoft 365
 - ✅ Deploying user must have **Global Admin Rights**  
 - ✅ Microsoft Defender for Endpoint must be provisioned. See [Defend Usage Guide](../Defend/Usage-Guide/index.md), under **Defender for Endpoint Workspace Creation**
 - ✅ [Security Defaults](https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-defaults#disabling-security-defaults) must be disabled in Entra ID  
-- ✅ [Certificate Authentication](https://learn.microsoft.com/en-us/azure/active-directory/authentication/how-to-certificate-based-authentication#step-2-enable-cba-on-the-tenant) must be disabled for SHIELD’s security groups
+- ✅ [Certificate Authentication](https://learn.microsoft.com/en-us/azure/active-directory/authentication/how-to-certificate-based-authentication#step-2-enable-cba-on-the-tenant) must be disabled for SHIELD's security groups
 
 ---
 
diff --git a/docs/SHIELD/Reference/Uninstall.md b/docs/SHIELD/Reference/Uninstall.md
@@ -12,7 +12,7 @@ The SHIELD platform uses multiple Microsoft 365 services to create configuration
     If you uninstall the architecture, **you will clear out any managed objects and configurations** deployed by the Deploy module. This procedure should only be followed if SHI explicitly instructs you to do so.
 
 !!! note "Stateless Server Reminder"
-    SHIELD’s application server is stateless. You can safely redeploy the app after cleanup without losing data stored in the Microsoft cloud (e.g., Intune tags, Entra groups).
+    SHIELD's application server is stateless. You can safely redeploy the app after cleanup without losing data stored in the Microsoft cloud (e.g., Intune tags, Entra groups).
 
 ---
 
@@ -74,4 +74,3 @@ Yes. SHIELD can be redeployed using the same app interface or script, as long as
 - [Deploy Usage Guide](../Deploy/Usage-Guide.md)
 - [Deployment](../Deploy/Deployment/index.md)
 - [Deploy Reference](../Deploy/Reference/index.md)
-
diff --git a/docs/SHIELD/Usage-Guide.md b/docs/SHIELD/Usage-Guide.md
@@ -37,7 +37,7 @@ Lifecycle actions include:
 - Assigning users to PAWs (Privileged Access Workstations)
 - Creating and removing privileged users
 
-These operations are triggered directly from the SHIELD app’s **Lifecycle Management** section.
+These operations are triggered directly from the SHIELD app's **Lifecycle Management** section.
 
 ---
 
@@ -126,4 +126,3 @@ SHIELD will soon support additional lifecycle workflows:
 - Use Lifecycle Management to adopt and manage devices/users
 - Task-level actions (commission, assign, etc.) are performed via the SHIELD UI
 - Each action links to a detailed guide and diagram for deeper understanding
-
