Skip to content
Andy Kemp Consulting

What's new#

AppDeploy is in beta. The version is on the splash screen and in Help, About, and AppDeploy offers each update when it starts (or Tools, Check for updates).

v0.5.1#

  • Opening a project and building the next version's installer (such as npp.8.9.9 after npp.8.9.8) keeps every setting: the commands get the new file name, and the version, publisher and logo come from the new installer. Before, a differently named installer started again from suggestions

v0.5.0#

Phases 5 and 6: listing and assignments.

  • Step 5, Listing: name, app version, description (Markdown), publisher, category (your tenant's Company Portal categories), a switch to show it as a featured app, information and privacy links, developer, owner, notes and the logo
  • The logo comes from the installer's own icon (up to 256 px, transparency kept), or choose a PNG or JPEG. The version, publisher and description are filled in from the installer's file details too
  • Step 6, Assign: type to search for groups (or paste an object ID), then add them as Required, Available or Uninstall, or exclude them; All users and All devices too. Each assignment has notifications, foreground download, availability and deadline times for Required, and a restart grace period
  • The upload sets the category and makes the assignments once Intune has published the app. If the assignments fail, the app is still uploaded and you can try them again from step 7
  • The project file saves the listing (with the logo) and the assignments
  • The app version is set through Microsoft Graph beta, because Graph v1.0 doesn't have it

  • Assignment filters come in a later update

  • Step 2 now suggests an uninstall command for Inno Setup, NSIS and Squirrel installers straight away, from the product name in the installer (Notepad++ gives "%ProgramFiles%\Notepad++\uninstall.exe" /S), instead of leaving it empty. A note under the box says it's a guess and that "Test the install" confirms it

  • Where there's no product name to go on, the command shows <app folder> to replace, and the review won't upload until it's replaced

v0.4.0#

Phase 4: install, detection and requirements.

  • Step 2, Install: AppDeploy recognises the installer (MSI, WiX Burn, Inno Setup, NSIS, Advanced Installer, InstallShield, Squirrel or a script) from the file itself, without running it, and fills in the silent install switches, with how confident it is and notes. Also: install as System or User, restart behaviour, maximum run time and return codes
  • Test the install on this PC: runs the install command with administrator rights (only the install is elevated, not AppDeploy), then reads what Windows recorded to suggest the uninstall command and detection. Then test the uninstall to check it removes the app
  • Step 3, Detection: MSI product code (with an optional version check), file or folder (exists, or a version at least), registry (key or value exists, equals, or a version at least) and PowerShell script rules. An MSI rule left on "the package's own" product code follows each new version
  • Step 4, Requirements: processor (x64, x86, Arm64), minimum Windows version, free disk space and memory
  • Step 7 is now the review: the app's name, publisher and description, everything that will be sent, then the upload
  • The project file saves steps 2 to 4, so the next version of the same installer starts with your settings
  • A maximum run time other than 60 minutes is set through Microsoft Graph beta after the app is created, because Graph v1.0 doesn't have it

v0.3.3#

  • Where the Windows sign-in broker can't run (Windows Server, some LTSC builds, Windows Sandbox, some VMs, or an app run as another user), sign-in and Set up this tenant fall back to signing in through your browser, instead of failing with error 0x80040154

v0.3.2#

  • Tools, Set up this tenant now creates AppDeploy's own app registration in your tenant (AKC AppDeploy, single-tenant, public client), its enterprise app and the admin consent, then fills in Settings. Nothing depends on Andy Kemp Consulting's tenant. The administrator signs in once through Microsoft Graph Command Line Tools; run again, it corrects the registration rather than adding another
  • Settings only holds the tenant's own registration; there's no AKC registration to choose

v0.3.1#

  • Tools, Set up this tenant: a Cloud Application Administrator grants admin consent once. AppDeploy checks their roles first, warns if they're Global or Privileged Role Administrator (more than it needs), and stops if they can't consent. The administrator's sign-in isn't kept
  • Day-to-day sign-in warns if the account holds Global, Privileged Role, Intune, Cloud Application or Application Administrator: AppDeploy only needs Intune's Application Manager role
  • Signing in before the tenant is set up says so, and how to fix it

v0.3.0#

Phase 3: sign-in and upload.

  • Sign in with your work account (top right), through the Windows sign-in broker, so Windows Hello, passkeys and device-based Conditional Access work
  • After sign-in, AppDeploy checks the permissions have admin consent and your account can manage Intune apps, and tells you if you're signed in with more than you need (Global or Intune Administrator)
  • Step 7, Review and upload: the name, publisher, description, install and uninstall commands, install context and detection, filled in from the package (all of it for an MSI), then every value that will be sent, then the upload
  • The upload creates the Win32 app, uploads the content in 6 MB blocks with progress, renews the upload address on long uploads, commits it with the package's encryption info and links to the app in the Intune admin centre
  • If an upload fails part-way, upload again to finish the same app, or remove it
  • Tools, Settings: use your organisation's own app registration (client ID and tenant)
  • Check for updates has moved to the Tools menu, as in the other AKC tools
  • Tokens stay in the Microsoft sign-in cache, encrypted for your Windows account; they, the upload address and the encryption keys are never logged

v0.2.0#

Phase 2: packaging.

  • Step 1, Package: drop or choose an MSI, an EXE or a folder, pick the setup file, and build the .intunewin. No command-line packager
  • A single installer is packaged on its own; a folder is packaged with everything in it, as Microsoft's packager does. Warns if the folder holds the packager itself or other .intunewin files
  • An MSI's product, version, publisher, product code, upgrade code and install context are read with Windows Installer (nothing is installed) and recorded in the package as Microsoft's packager does
  • Every package is checked after it's built: it decrypts, and its HMAC, size and SHA-256 match
  • Packages are saved in %LOCALAPPDATA%\AKC\AppDeploy\Packages, or a folder you choose
  • Projects: File, New, Open and Save, so an app can be packaged again for its next version
  • Tested against Microsoft's IntuneWinAppUtil on every build: AppDeploy reads Microsoft's packages, and both give the same files, Detection.xml and MSI details

v0.1.0#

Phase 1: the app shell, from the Win11 Image Prep template.

  • AKC theme (copper, Inter), Atlas splash, About, welcome window and progress window
  • The AppDeploy icon: a copper box with an upward arrow, instead of the AK monogram
  • Numbered wizard steps: Package, Install, Detection, Requirements, Listing, Assign, Review and upload (not built yet)
  • Updates from downloads.andykemp.com/appdeploy/latest.json, checked against SHA-256. Updates in place without administrator rights where it can, and uses the elevated updater only for folders such as Program Files
  • Organisations can turn updates off with ManagedUpdates = 1 under HKLM\SOFTWARE\Policies\Andy Kemp Consulting\AppDeploy
  • Settings and logs in %LOCALAPPDATA%\AKC\AppDeploy. Logs mask tokens, SAS URIs and encryption keys