Store Administration

Store Administration groups the portal’s configuration into focused nodes, one per domain, instead of a single Settings tab. Each node is named for what it configures: Permissions, Categories, Tags, Branding, Storefront, Deployment, Integrations, Communications, System, and License. Settings that have a natural working surface live on that surface, so update cadence sits on the App Updates page and catalog sourcing sits on the App Catalog page, rather than on a separate settings screen.

If you are upgrading from an earlier version, the old Settings tab has been retired. Use the tables below to find where each setting now lives.

Where Each Setting Lives

Settings inside Store Administration:

Setting	Node
Admin, Approver, User Access, and Request on Behalf group assignments	Permissions
Category colors	Categories
Tag colors	Tags
Logo, favicon, brand colors, text, and the dark-mode theme toggle	Branding
Max featured apps, categories on home page, hero app, compatible-apps filter, My Devices tab, letting users ask a device to check in	Storefront
Group name prefix, auto-create Entra ID groups	Deployment
BI for Intune connection	Integrations
Notifications, Terms of Service, portal URL	Communications
Self-update and release channel, custom domain, currency, catalog sourcing	System
License key and entitlement status	License

Settings that live on the surface they configure:

Setting	Where to find it
Automatic update checking, check interval, update notifications, auto-deploy through rings	App Updates page, Update Settings panel
Help desk cost per ticket (ROI)	Analytics report
Require manager approval by default	Approval Workflows builder
Setup Wizard	Getting Started (top-level entry)

The rest of this page documents the Store Administration nodes in detail. For the settings that moved onto other surfaces, follow the links above.

Permissions

Control who has admin and approver access to the portal, and who can request on behalf of others.

Setting	Description
Admin Group	Optional Entra ID group Object ID. Members have full admin access to sync apps, manage the portal, and view all requests. The group administers alongside the initial administrator (the account that ran the deployment) and never replaces them.
Approver Group	Entra ID group Object ID. Legacy, and no longer an authorization source. Membership no longer allows anyone to approve or reject anything: from 1.39.0 a request is decided only by the stage that names the person or their group. The setting is kept because members can still open other people’s requests to read them, and because the upgrade uses it to convert the approvals it used to imply into real per-app workflow stages. To let somebody approve, put them in a stage on the app’s workflow.

Who administers the portal. Two authorities, either of which is enough: the initial administrator, recorded automatically when a person deploys the portal, and the optional Admin Group. Saving or clearing the Admin Group here never removes the initial administrator, so if the group is deleted, emptied or mistyped, the initial administrator can still sign in and correct it. The portal refuses a change that would leave nobody able to administer it.

Lost admin access? Sign in as the initial administrator and fix the Admin Group here. If the portal was deployed by automation and has no initial administrator, set AppSettings__AdminGroupId as an App Service environment variable (or in appsettings.json) and restart. Editing the database by hand is not a supported recovery.

Recommended Conditional Access Policy

Since App Store for Intune is used to request apps for Intune-managed devices, we recommend protecting access to the portal with a Conditional Access policy that requires:

• Managed device, the device accessing the portal must be enrolled in Microsoft Intune.
• Compliant device, the device must meet your organization’s compliance policies.

This ensures users can only request apps from trusted, compliant devices.

Prerequisites

Before creating the policy:

1. You must have Microsoft Entra ID P1 or P2 license (or Microsoft 365 E3/E5, etc.).
2. You need the Conditional Access Administrator or Global Administrator role.
3. Have at least one compliance policy configured in Microsoft Intune.

Creating the Conditional Access Policy

1. Go to Conditional Access

   • Go to Azure Portal.
   • Go to Microsoft Entra ID > Security > Conditional Access.
   • Select + New policy.

2. Name the policy

   • Enter a descriptive name: App Store for Intune - Require Compliant Device.

3. Configure Assignments - Users

   • Under Users, select 0 users and groups selected.
   • Select Include > All users.
   • (Optional) Under Exclude, add a break-glass admin account for emergency access.

4. Configure Assignments - Target Resources

   • Under Target resources, select No target resources selected.
   • Select Cloud apps.
   • Select Include > Select apps.
   • Search for and select your App Store for Intune app registration (there is a single registration):
     • App Store for Intune (or whatever you named your app registration).
   • Select Select.

5. Configure Conditions (optional)

   • Under Conditions > Device platforms.
   • Select Not configured.
   • Set Configure to Yes.
   • Select Include > Select device platforms.
   • Check: Windows, iOS, Android (the platforms you manage).
   • Select Done.

6. Configure Access Controls - Grant

   • Under Grant, select 0 controls selected.
   • Select Grant access.
   • Check Require device to be marked as compliant.
   • Check Require Microsoft Entra hybrid joined device (optional, for hybrid environments).
   • Select Require one of the selected controls (OR) or Require all the selected controls (AND) based on your requirements.
   • Select Select.

7. Configure Session Controls (optional)

   • Under Session, you can configure:
     • Sign-in frequency: Require re-authentication periodically.
     • Persistent browser session: Disable persistent sessions for extra security.

8. Enable the policy

   • Set Enable policy to Report-only first to test.
   • Select Create.

9. Test and enable

   • Monitor the Sign-in logs for a few days in Report-only mode.
   • Verify legitimate users can access the portal from compliant devices.
   • Verify access is blocked from non-compliant or unmanaged devices.
   • Once verified, edit the policy and change to On.

Policy Summary

Setting	Value
Name	App Store for Intune - Require Compliant Device
Users	All users (exclude break-glass account)
Cloud apps	App Store for Intune app registration
Conditions	Device platforms: Windows, iOS, Android
Grant	Require device to be marked as compliant
Enable policy	Report-only (then On after testing)

Troubleshooting Access Issues

If users report they cannot access the portal:

1. Check Sign-in logs

   • Go to Microsoft Entra ID > Sign-in logs.
   • Filter by the user and application.
   • Look for Failure entries and check the Conditional Access tab.
   • The tab shows which policies applied and why access was denied.

2. Common issues

   Issue	Solution
   Device not enrolled	User needs to enroll their device in Microsoft Intune
   Device not compliant	User needs to resolve compliance issues (updates, encryption, etc.)
   Using personal device	User needs to use their work-managed device
   Policy excluding wrong users	Review the Exclude settings in the CA policy

3. Verify device status

   • Go to Microsoft Intune admin center > Devices.
   • Search for the user’s device.
   • Check Compliance status and any failed compliance policies.

Alternative: Allow Browser Access with App Protection

If you need to allow browser access from unmanaged devices (less secure), you can create an alternative policy:

1. Create a second CA policy for browser access.
2. Target the same apps.
3. Under Conditions > Client apps, select Browser only.
4. Under Grant, require Approved client app or App protection policy.
5. This allows access from unmanaged devices but with some protection.

Recommendation: For maximum security, require compliant managed devices. App Store for Intune is designed for employees requesting apps on their managed devices, so this policy aligns with the intended use case.

Categories and Tags

Categories and Tags each have their own node in Store Administration. Today both hold the color settings that control how category and tag chips render across the catalog.

• Categories holds category colors. Categories are the shelves an app browses under and stay in sync with Microsoft Intune in both directions. See App Management.
• Tags holds tag colors. Tags are portal-only labels for organizing and filtering the catalog. See App Tags.

Branding

Configure the portal’s visual identity for all users.

Setting	Description
Logo	Upload the logo shown in the portal header.
Favicon	Upload the browser-tab icon.
Brand colors	Set the accent colors applied across the portal.
Brand text	Set the portal name and footer text.
Enable dark mode	Set the default dark-mode theme for all portal users.

Dark Mode Behavior

The portal resolves dark mode from three sources, in priority order:

1. User preference, users can select the sun or moon icon in the header to toggle dark mode for themselves.
2. System preference, if the user has not set a preference, the portal auto-detects the operating system’s dark mode setting.
3. Admin default, falls back to the dark-mode setting configured in Branding.

User preferences are stored in localStorage and persist across sessions. Users can always override the admin default for their own viewing preference.

Dark Mode Styling

When dark mode is active, the portal uses a vignette-style design inspired by Microsoft Learn and the Microsoft Intune admin center:

• Main content area: Darkest (#1a1a1a) with a subtle inset shadow for depth.
• Header and footer: Medium dark (#252525) with subtle borders.
• Outer edges: Lighter dark gray (#2d2d2d).

This creates a professional look where the center content draws focus while the periphery provides visual framing.

Note

Dark mode settings persist across page refreshes and sign-in or sign-out cycles. The admin default is loaded through a public API endpoint so it applies even before the user authenticates.

Storefront

How the store presents itself to your users: how apps are shown, and which tabs users get.

Setting	Description
Maximum Featured Apps	How many featured apps appear in the home page carousel. 0 shows all featured apps from Intune.
Categories on Home Page	How many category rows the home page shows. Default 3.
Hero App	One app to feature prominently at the top of the home page. Only visible, supported, featured apps are offered.
Show only apps that run on the device being used	Opens the catalog filtered to the platform the browser reports. Off by default, because users are told they can shop for any of their devices from any device.
Let users see apps for their other devices	Whether a user can look past that filter. On by default. Leave it on unless you have a reason not to: with it off, someone on a phone cannot browse the Windows apps they will need at their desk.

The platform behind the compatible-apps filter comes from the browser, so it is a guess. It decides what to show and never what gets installed; that question is answered by the device identity Microsoft Entra ID attests, which a user cannot change. The filter also stays off entirely when the browser could not be identified, rather than emptying the catalog on a wrong guess.

My Devices

Also on this node, because My Devices is a tab in the store. Both settings are off by default.

Setting	Description
Give users a My Devices tab	Shows each user the devices they are the primary user of in Intune, with whether each one can reach company resources, when it last checked in, and its manufacturer, operating system, ownership, and category. Read-only, and it needs no permission beyond the one the portal already uses to read devices.
Let users ask a device to check in	Adds a Check in now button to My Devices. The device collects any apps waiting for it, refreshes its policies, and is re-evaluated for compliance. This is the Sync action from the Company Portal app, not the Check status link on the Company Portal website, which uses an internal Microsoft API. Appears only once the tab itself is turned on.

About the check-in permission

Check status needs the Microsoft Graph permission DeviceManagementManagedDevices.PrivilegedOperations.All on the App Service’s managed identity. Microsoft offers no narrower permission for a device check-in: the same grant also allows wipe, retire, and rename. App Store never calls those.

Because the granted authority is wider than the feature, the permission is not part of the standard setup snippet and has to be granted deliberately. See Grant Microsoft Graph permissions.

The Storefront page tells you whether the permission is in the token this app is currently using, which is what actually decides whether a check-in succeeds.

That is not the same question as whether you have granted it. Azure caches the token the app signs its Graph calls with, and that cache lives outside the app process.

A newly granted permission can take up to 24 hours to take effect

There is no way to force it. Restarting the App Service does not clear the cached token, and neither does stopping and starting it; both were tested. It clears when the token expires, up to 24 hours after it was issued.

Until then, Check in now appears and reports that the permission is missing. Your grant is fine and there is nothing else to do. Grant the permission, then come back the next day.

You can turn the setting on either way. It never blocks on this.

A user can ask for a check-in on a device they are the primary user of, or on a device they are signed in to right now. Any other device answers the same way as one that does not exist. Every attempt is written to the audit log, refusals included, as Device.SyncDenied.

Which device a device-assigned app installs on is set per app, in the App settings wizard’s Assignment step, not here.

Deployment

Deployment holds the defaults the portal uses when it creates Entra ID groups and Intune assignments for published apps.

Setting	Description
Group Name Prefix	Prefix used when auto-creating Entra ID groups (default: AppStore-). Groups are named {prefix}{AppName}-Required. Use this to identify portal-managed groups in your tenant.
Auto-create Entra ID groups	Automatically create a security group when an app does not have a target group configured.

Integrations

Integrations holds the connection to BI for Intune. Configuring the connection here lets App Store for Intune data appear alongside your other Microsoft Intune reporting. Additional integrations will be added to this node in future releases.

Communications

Communications holds all notification, messaging, and Terms of Service settings, including company information, email notifications, Microsoft Teams bot notifications, approval reminders, and stale-request escalation. See Communications for the full reference.

System

Settings about the running instance itself rather than the store’s content.

Catalog Sourcing

Where this instance sources its app catalog from, and how packages are trusted and displayed. These were previously on the App Catalog page.

Setting	Description
Catalog Repository URL	GitHub repository for catalog packages. Leave empty for the default Microsoft repository. The App Catalog, packaging and update checks all use this repository. Saving a different URL rebuilds the App Catalog from it straight away. See Configure WinGet Integration.
Sync catalog now	Refreshes the App Catalog from the repository now, instead of at the next daily refresh, and shows the result of the last refresh.
GitHub Personal Access Token	Optional. The catalog is populated automatically, so browsing, searching and publishing all work without one. Provide a token for the “Show More Results” deep search, for higher GitHub rate limits when publishing in volume, or to read a private custom repository.
Verify manifest integrity against Microsoft’s signed index	Before packaging a catalog app, look it up in Microsoft’s signed community index and refuse to package anything not present there. Defends against a tampered or substituted manifest.
Resolve catalog icons automatically	Fetches an app’s icon once, server-side, and caches it in your own database. The browser never makes the call and nothing about your tenant is sent. Turn it off for egress-strict environments.

System holds the instance-level settings that configure the deployed portal as a whole and belong to no content domain: self-update and release channel, custom domain, and currency.

Version and Updates

The System node displays version information and controls how the portal updates itself:

Setting	Description
Current Version	Displays the installed portal version, build date, and environment.
Automatically check for updates	When enabled, the portal periodically checks for new versions.
Show update notifications	When enabled, displays a notification banner when updates are available.
Check for Updates	Manual button to check for available updates.
Install Update	One-click button to download and install updates (requires configuration).
Release Channel	Select the update channel: Latest (Recommended) for the supported production release, or Staging (Preview Features) for preview builds, which are for lab and non-production evaluation only. A new installation starts on the channel it was deployed from.
Number of update apps to retain	How many previous update applications App Store keeps in Intune alongside the current one. Default 1, range 0 to 5. Keeping one gives a bridge when a vendor releases again before the previous rollout has finished its rings: devices still working through the older update carry on while the new one starts. The current updater is additional, so the live total per app is one plus this number.
Number of rollback versions to retain	How many completed historical versions stay available for rollback. Default 3, range 1 to 10. Each retained version keeps its packaged .intunewin and the metadata needed to rebuild it, so higher values give more rollback depth and use more Blob Storage. Retention is by count, not age: a retained version stays available whether it is a week or two years old. Lowering this permanently deletes the rollback packages for versions outside the new count, and raising it again does not bring them back.

When an update is available, you see:

• An update badge with the new version number.
• A link to release notes.
• An Install Update button (if in-app updates are configured).

What Install Update checks (1.39.0): before the new package is applied, the portal verifies that it comes from the configured release host over HTTPS and, when the release publishes a checksum, that the downloaded package matches it. A package that fails either check is refused, and the refusal is written to the audit log. A successful install is also audited, including the package URL that was replaced: putting that value back into the WEBSITE_RUN_FROM_PACKAGE app setting is how to revert an update by hand. Two optional app settings apply: Application__ReleasesBaseUrl (where releases are fetched from and the only host the portal will install from; leave unset for the PowerStacks release host) and Application__RequirePackageDigest (true refuses any package without a published checksum).

Enabling In-app Updates

The portal supports one-click updates directly from the Admin Dashboard. This feature downloads the latest release and deploys it through Azure’s Kudu ZIP deploy API.

Prerequisites:

• Portal must be running in Azure App Service.
• Deployment credentials must be configured.

Configuration steps:

1. Get deployment credentials from Azure Portal:

   • Go to your App Service > Deployment Center > FTPS credentials.
   • Copy the Username (starts with $, e.g., $app-apprequest-prod-abc123).
   • Copy the Password.

2. Add app settings in Azure Portal:

   • Go to your App Service > Configuration > Application settings.
   • Add these settings:

   Name	Value
   Deployment__PublishUser	Your FTPS username (e.g., $app-apprequest-prod-abc123)
   Deployment__PublishPassword	Your FTPS password

3. Using the update feature:

   • Go to Admin > System.
   • Select Check for Updates to see if a new version is available.
   • If configured correctly, an Install Update button appears.
   • Select it to download and deploy the update automatically.
   • The application restarts during the update process.

Note: The Install Update button only appears when:

• The portal is running in Azure App Service (not locally).
• Deployment credentials are properly configured.
• An update is available.

Manual Updates

If in-app updates are not configured, you can update manually using either method below:

Back up the database before upgrading

App Store applies database migrations automatically when the new version starts. Before a major upgrade, take a backup so you can roll back if a migration causes problems: export a BACPAC to your storage account, or note the current UTC timestamp to use Azure SQL point-in-time restore. See Disaster recovery.

Method 1: Kudu ZIP Deploy (recommended for existing installations)

For existing deployments, use the Kudu ZIP deployment feature:

1. Download the latest application package: AppRequestPortal.zip.
2. In Azure Portal, go to your App Service.
3. Select Advanced Tools > Go (opens Kudu).
4. Select Tools > Zip Push Deploy.
5. Drag and drop the downloaded ZIP file into the deployment area.
6. Wait for deployment to complete (watch the logs).
7. Restart your App Service if needed.
8. Database migrations run automatically on next startup.

Note

This method preserves your existing configuration and database. The ZIP contains only application files.

Method 2: Fresh install from the Azure Marketplace (new installations only)

For a brand-new installation, deploy from the Azure Marketplace. See Install from the Azure Marketplace for the full walkthrough.

Caution

A fresh Marketplace deployment provisions new resources and should target a new, empty resource group. To update an existing deployment, use Method 1 above.

Currency

Currency sets the tenant-wide format used wherever money appears in the portal, including app cost and the ROI figures on the Analytics report. It is a formatting setting only and does not affect billing.

Custom Domain Configuration

The System node includes a Custom Domain section for configuring a custom domain (e.g., apps.yourdomain.com) for your portal.

Prerequisites

Before configuring a custom domain:

1. Your DNS must be configured with the appropriate CNAME or A record pointing to your Azure App Service.
2. Your Azure App Service must be on the Basic tier or higher (required for custom domains with SSL).

Configuring via Admin Dashboard

1. Go to Admin > System.
2. Go to the Custom Domain section.
3. Read the prerequisites and ensure DNS is configured.
4. Select Configure Custom Domain in Azure.
5. This opens the Azure Portal with a pre-configured ARM template that:
   • Adds your custom domain to the App Service.
   • Creates a free Azure-managed SSL certificate.
   • Binds the certificate to your domain.

After Configuration

Once your custom domain is configured:

1. Update Microsoft Entra ID redirect URIs, add your custom domain URLs to your App Registration.
2. Update Portal URL, in Communications > Email Notifications, update the Portal URL to use your custom domain.
3. Test authentication, sign out and sign back in to verify authentication works.

Note

For detailed DNS configuration, certificate options, and troubleshooting, see Custom Domains.

License

The portal requires a valid PowerStacks license to operate. License status is displayed in the Admin Dashboard and affects portal functionality.

Viewing License Status

1. Go to Admin > License.
2. The License node shows:
   • Current license status (Valid, Expired, Over Device Limit, etc.).
   • License type and expiration date.
   • Device count vs. licensed limit.
   • Last validation timestamp.

License Validation

The portal automatically validates your license:

• On application startup.
• Every 24 hours.
• When you manually select Validate License.

To force a validation check, select the Validate License button in the License node.

If the license service cannot be reached, the last successful validation stays in effect for up to 7 days. During that time the portal keeps working on the last known license state; after it, the license is treated as unverified until a validation succeeds.

Updating the License Key

1. Go to Admin > License.
2. Enter your new license key.
3. Select Save License Key.
4. The portal validates the new key and displays the result.

Alternatively, use the Setup Wizard (reachable from the top-level Getting Started entry) to enter or update your license key.

License Warnings

Users see warning banners in the following situations:

Condition	Banner Message
License expiring soon (30 days or fewer)	“License expires in X days. Please contact your IT administrator to renew.”
Device count in grace period (up to 3% over limit)	“Device count exceeds license limit by X devices. Please contact your IT administrator to upgrade.”
License invalid or expired	Warning message explaining the issue

Note

When device count exceeds the license limit by more than 3%, new app requests are blocked until the license is upgraded or device count is reduced.

Device Count

The portal tracks managed devices from Microsoft Intune that have checked in within the last 30 days. Device count is updated:

• During each app sync from Microsoft Intune.
• When you select Update Device Count in the License node.