Documentation

Troubleshooting

Solutions to common issues and frequently asked questions about self-hosting IntuneGet.

Quick Diagnosis

Start by checking the health endpoint to identify which components are working:

bash
curl https://your-app.vercel.app/api/health

Expected response:

json
{
  "status": "healthy",
  "mode": "self-hosted",
  "services": {
    "database": true,
    "auth": true,
    "pipeline": true
  }
}

If any service shows false, focus troubleshooting on that component.

Common Error Messages

Authentication Errors

AADSTS50011: The reply URL specified in the request does not match

The redirect URI in your request doesn't match the configured URIs.

Solution:

  1. Go to Azure Portal > Your App Registration > Authentication
  2. Verify your URL is listed (e.g., https://your-app.vercel.app)
  3. Ensure it's added as a SPA redirect, not Web
  4. Check for trailing slashes - they must match exactly

AADSTS65001: The user or administrator has not consented

Admin consent has not been granted for your tenant.

Solution:

  1. Contact your Global Administrator
  2. Have them visit: https://login.microsoftonline.com/YOUR_TENANT/adminconsent?client_id=YOUR_CLIENT_ID
  3. They must click Accept on the consent screen

AADSTS700016: Application with identifier was not found

The client ID is incorrect or the app was deleted.

Solution:

  1. Verify NEXT_PUBLIC_AZURE_AD_CLIENT_ID is correct
  2. Check the app still exists in Entra ID
  3. Compare the ID in your .env with the Overview page in Azure

Database & Packager Errors

Database not found / SQLite error

The SQLite database file cannot be accessed or created.

Solution:

  1. Verify DATABASE_MODE is set to "sqlite"
  2. Check DATABASE_PATH points to a writable location (default: ./data/intuneget.db)
  3. Ensure the /data directory exists and has write permissions
  4. For Docker: verify the volume mount is configured correctly

Packager API key invalid / Connection refused

The local packager cannot authenticate or connect to the web app.

Solution:

  1. Verify PACKAGER_MODE is set to "local"
  2. Check PACKAGER_API_KEY matches between the web app and the packager service
  3. Ensure the packager Windows machine can reach your web app URL
  4. Verify NEXT_PUBLIC_URL is correct and accessible

Unmanaged Apps Errors

Permission error on Unmanaged Apps page

Missing DeviceManagementManagedDevices.Read.All permission.

Solution:

  1. Go to Settings > Permissions tab and run "Check Permissions"
  2. If the DeviceManagementManagedDevices.Read.All permission shows as missing, have a Global Administrator re-grant admin consent
  3. Add the permission in Azure Portal > App Registration > API Permissions if it is not listed

Webhook delivery failed

Webhook notifications are not being received by the target endpoint.

Solution:

  1. Verify the webhook URL is correct and publicly accessible
  2. Check the webhook delivery logs in Settings > Notifications
  3. Ensure the endpoint accepts POST requests with JSON payloads
  4. For Slack/Teams/Discord, verify the incoming webhook URL has not been revoked

Pipeline Errors

Workflow not triggering

Deployments get stuck in "pending" status.

Solution:

  1. Verify GITHUB_PAT has repo and workflow scopes
  2. Check workflows are enabled in your fork's Actions tab
  3. Verify GITHUB_OWNER and GITHUB_REPO match your fork
  4. Check the PAT hasn't expired

Callback verification failed

Pipeline completes but status doesn't update.

Solution:

  1. Verify CALLBACK_SECRET matches in both GitHub Secrets and .env
  2. Check NEXT_PUBLIC_URL is accessible from the internet
  3. Look at the workflow run logs in GitHub Actions

IntuneWinAppUtil failed

Packaging fails for specific apps.

Solution:

  1. Check the app exists in Winget: winget show {app-id}
  2. Verify the app has a supported installer type
  3. Check workflow logs for specific error messages
  4. Some apps may not be compatible with IntuneWinAppUtil

Debugging Tips

Check Logs

Vercel: Dashboard > Your Project > Logs

Docker: docker-compose logs -f

Browser Console

Press F12 and check the Console and Network tabs for errors and failed requests.

GitHub Actions

Check your fork's Actions tab for workflow run details and error messages.

Environment Check

Verify all environment variables are set. Missing or incorrect values cause most issues.

Environment Variable Checklist

Verify each variable is set correctly:

VariableCheck
DATABASE_MODESet to "sqlite" for self-hosted deployments
DATABASE_PATHPath to SQLite file (default: ./data/intuneget.db)
PACKAGER_MODESet to "local" for the local packager service
PACKAGER_API_KEYShared secret between web app and packager service
NEXT_PUBLIC_AZURE_AD_CLIENT_IDUUID format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
AZURE_CLIENT_SECRETShould not be expired, contains ~
NEXT_PUBLIC_URLFull URL with https://, no trailing slash

Frequently Asked Questions

The complete setup typically takes 1-2 hours if you follow the guide step by step. Most of this time is spent on Entra ID configuration. The actual deployment with Docker takes only a few minutes.

Yes! IntuneGet is free and open source under the AGPL-3.0 license. The self-hosted version uses SQLite (embedded, no external service needed) and runs in Docker. There are no external database costs. If you use GitHub Actions for packaging (optional), private repos may incur costs after 2,000 minutes/month.

You need permission to create app registrations, which is often available to all users by default. However, a Global Administrator is needed to grant admin consent for the application permissions that allow uploading to Intune.

The self-hosted version uses SQLite by default, which requires zero configuration. The hosted version (intuneget.com) uses a different backend. For self-hosting, SQLite is recommended as it provides simple backups (just copy the file) and no external dependencies.

Pull the latest changes from your upstream remote (git fetch upstream && git merge upstream/main), then redeploy. For Docker: docker-compose down && docker-compose build --no-cache && docker-compose up -d. Check release notes for any required migrations.

Yes! IntuneGet is designed as a multi-tenant application. Users from different Microsoft 365 organizations can sign in and deploy apps to their respective Intune tenants, as long as their admin has granted consent. The MSP features provide additional multi-tenant management capabilities.

Currently, IntuneGet only supports apps available in the Winget repository. You can use the Unmanaged Apps feature to discover applications on your devices and manually link them to Winget packages if a match exists. Custom app support is on the roadmap for future releases.

Unmanaged apps are applications discovered on your Intune-managed devices that are not yet deployed through Intune. IntuneGet detects these apps, matches them against the Winget repository, and lets you claim them for deployment. This requires the DeviceManagementManagedDevices.Read.All permission.

The MSP (Managed Service Provider) features allow you to manage multiple client tenants from a single dashboard. You can batch-deploy applications across tenants, manage team access with roles, configure webhooks for deployment notifications, view audit logs, and generate cross-tenant reports.

IntuneGet supports email notifications (real-time, daily digest, or critical-only) and webhooks for Slack, Microsoft Teams, Discord, or custom HTTP endpoints. Webhooks are signed with HMAC for security. Configure both in the Settings page under the Notifications tab.

Getting Help

Before Opening an Issue

  • Search existing issues for similar problems
  • Include your deployment method (Vercel, Docker, etc.)
  • Share relevant error messages (redact sensitive info)
  • Describe what you expected vs. what happened

Still Need Help?

Review the detailed setup guides for each component: