M.A.D. Blog - Modern Application Deployment https://docs.microsoft.com/archive/blogs/sgern/feed.xml Blog about deploying Apps in a modern Way Mon, 04 Feb 2019 15:00:17 GMT en-US hourly 1 MSIX: Package Support Framework Part One - The Blueprint https://docs.microsoft.com/archive/blogs/sgern/msix-package-support-framework-part-one-the-blueprint Mon, 04 Feb 2019 15:00:13 GMT https://blogs.msdn.microsoft.com/sgern/?p=3955 AppXManifest.xml is evaluated. Within the manifest the Application Tag defines executable to run: MyApp.Exe and then Application gets started To implement an MSIX Application that needs the  Package Support Framework configuration there are quite some significant differences . As Follows   Shell tries to execute MSIX Package(MyApp.exe) Once again the content of AppXManifest.xml is evaluated This time though the  Application Tag defines executable to run:PsfLauncher32.exe (PsfLauncher64.exe is there for 64Bit Applications) PsfLauncherXX.exe is executed and reads a Config.Json file Config.Json file contains target executable and File-Redirection rules PsfLauncherXX.exe launches target executable This is just the high level overview and blueprint we'll use in our series of blog posts to help you successfully implement your first application fix.   Look out for our upcoming blog series on  
  1. Packaging your Application
  2. Acquiring the PSF
  3. Configuring PSF
  4. Package PSF into MSIX Package
Matthias Herfurth, Johannes Freundorfer and Ingmar Oosterhoff]]> Announcement Modern Application Deployment Day in March next year https://docs.microsoft.com/archive/blogs/sgern/announcement-modern-application-deployment-day-in-march-next-year Fri, 30 Nov 2018 09:15:39 GMT https://blogs.msdn.microsoft.com/sgern/?p=3935 Just to let you know and set right expectations - we decided that the spoken language for this Event is German. If you are interested to run a similar event in English and maybe closer to your location let me know. Here is the Link to the Registration Form: REGISTRATION Thank you and I hope to see you there Warm Greetings Sebastian - Escalation Engineer App-V and MSIX  ]]> INTUNE - Intune and Autopilot Part 4 - Enroll your first device https://docs.microsoft.com/archive/blogs/sgern/intune-intune-and-autopilot-part-4-enroll-your-first-device Tue, 27 Nov 2018 12:50:53 GMT https://blogs.msdn.microsoft.com/sgern/?p=3785
  • INTUNE – Intune and Autopilot Part 1 – The Blueprint
  • INTUNE – Intune and Autopilot Part 2 – Setting up your environment
  • Intune and Autopilot Part 3 – Preparing your environment
    • we guided you through all the necessary steps to get your Azure trial Tenant up and running, and how to prepare your Intune environment further. Now it is time that we enroll our first device with Autopilot. We would recommend using a virtual machine for this first step. When you are going to follow these steps along, the end result will be that the Out-of-Box experience (OOBE) will be customized with our company name and logo, as shown in the image below: The requirements to enroll a device with Autopilot:
    • Windows 10 Build 1703 Professional, Enterprise or Education
    • Internet Access
      If your Virtual Machine is located behind a Firewall or Proxy Server, ensure that the following URLs are reachable and ports are open so the device used for Autopilot is able to connect to the required cloud services:   URLs:
    • ctldl.windowsupdate.com
    • download.windowsupdate.com
    Ports:
    • HTTPS 443
    • HTTP 80
      If you run into issues while following this guide, please retry all the steps with a virtual machine directly connected to the internet and ensure all the URL's and ports listed in the following article are reachable https://docs.microsoft.com/en-us/intune/network-bandwidth-use   Now, with all preparations taken care of, we login into our virtual machine and use a Powershell Script provided by Michael Niehaus to harvest the Hardware details. The Script can be found at: https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo The PowerShell script will gather all the required Information and puts it into an csv file that needs to be uploaded. This Script will only run in Windows 10 1703 and higher - it cannot run in any earlier version of Windows nor WindowsPE. Execute the Script in an elevated powershell prompt 
    Install-Script -Name Get-WindowsAutoPilotInfo
    You'll be prompted 3 times. Please answer with Y to continue It is also possible to download the script. After we have installed the Script we need to modify the execution policy to be able to successfully run the script: 
    Set-ExecutionPolicy bypass
    And finally run it to collect the data: With the CSV file prepared, we can now log in to our Azure Tenant and upload the file to Intune. Login to your Azure Tenant and navigate to the Windows enrollment page within Intune, click on the "Import" button: Select the file and upload it by pressing "import" on the bottom of this page: The file will now be uploaded. This could take up to 15 minutes. Once the upload and sync process have finished successfully we need to assign a Autopilot profile to the newly added device. As this is our first enrollment we need to create a new Autopilot profile. Please navigate to the deployment profiles within Intune and click the "Create profile" button. Now we need to provide a Name, select "User-Driven" as our Deployment Method and select "Azure AD joined" as Join to Azure. Those are our required fields. In the OOBE configuration we can configure the behavior we want. Just keep in mind - the more you show - the more user interaction we have: Once you have configured your Autopilot profile click on "create" and head over to Azure Active Directory to create a new Security Group and make the device member of this group: Once we finish setting up the group, and made the device member of the group, we can proceed assigning the Autopilot Profile to this security group. Head over to the Autopilot Deployment Profiles blade in Intune, select the Autopilot profile we just created, and on the details tab of this profile click on Assignments to add the newly created security group: Optional: If preferred you can also assign a specific user to that device: Now we need to wait for the sync in the background to complete. Once that's done, we're ready to deploy. You can check the Devices Tab if the profile is showing as Assigned for the device. This might take a bit of time Once that's completed we can start our Virtual Machine and enroll it automatically into Azure AD and Intune with Autopilot. To reset the machine to the OOBE Phase I use Sysprep and take a Snapshot afterwards. When the VM starts again you have to select region and keyboard layout. If you have done all preparations correctly you should end up with the custom Login of your Azure tenant. In our example I assigned it to a specific user so  it  prompts me for the password of the user I assigned to that device in the optional step: After the Setup has been completed you can verify the successful Azure Join of your device as well as the Intune enrollment within the Azure Dashboard Congratulations - you just enrolled your first device with Autopilot! In following blog entries we will have a more detailed look into some Autopilot scenarios like setting up Kiosk & Multi-Kiosk, Firstline workers, shared devices, using dynamic groups and so on. If you have any question just leave them in the comments.   Matthias Herfurth, Ingmar Oosterhoff and Johannes Freundorfer  ]]>         Support Lifecycle App-V and the MSIX confusion https://docs.microsoft.com/archive/blogs/sgern/support-lifecycle-app-v-and-the-msix-confusion Wed, 17 Oct 2018 15:01:50 GMT https://blogs.msdn.microsoft.com/sgern/?p=3775 here. But they Key Bullet points are:
    1. If you are investing in App-V now or have already in App-V > Your investment is safe.
    2. SO Investment in App-V is a good one as many learnings and Techs from App-V made MSIX possible...
    3. And with the things to come you are ahead of the curve – if you have App-V now.
    4. If you about to start with App-V now - Don't stop!
      As the Insights are similar (based on AppX) it’s not like going from App-V 4 to 5 – it’s like going from 5 to 6 where you need to convert your existing App-V Packages into the new format. You can download the Tool here: https://www.microsoft.com/en-us/p/msix-packaging-tool/9n5lw3jbcxkf#activetab=pivot:overviewtab And this time it’s much easier from an inside perspective to make an App-V Package an MSIX Package rather make a App-V 4 Package an App-V 5 Package.   So again App-V can be seen as an (early) investment in MSIX. To see what is coming in MSIX take  a look: https://www.youtube.com/watch?v=FKCX4Rzfysk I hope this clarifies some points.   Thanks   Sebastian Gernert - Escalation Engineer App-V]]>         INTUNE - Intune and Autopilot Part 3 - Preparing your environment https://docs.microsoft.com/archive/blogs/sgern/intune-intune-and-autopilot-part-3-preparing-your-environment Thu, 11 Oct 2018 12:54:20 GMT https://blogs.msdn.microsoft.com/sgern/?p=3725
  • Go to https://portal.azure.com, log in and Click Azure Active directory >> Company branding >> Configure
    • For AutoPilot, the Sign-in page text and the "Square logo image", highlighted below, need to be specified. The other are optional
    • Specify your sign-in page text, and upload your square logo and click Save
    • Another key part is the Azure Active Directory tenant name. This was filled in when you created the tenant and can be modified by clicking Azure Active directory >> Properties, and changing the Name
    • As a prerequisite, we need to enable automatic enrollment.
    This can be done by clicking Azure Active directory >> Mobility (MDM and MAM) >> Intune Change the MDM user scope to All. Leave MAM set to None and click save Looks like we're all set up for AutoPilot. Next steps would involve adding some devices to windows AutoPilot and create a profile of settings, but we'll cover that in the next post   Ingmar Oosterhoff, Matthias Herfurth and Johannes Freundorfer    ]]>         INTUNE - Intune and Autopilot Part 2 - Setting up your environment https://docs.microsoft.com/archive/blogs/sgern/intune-intune-and-autopilot-part-2-setting-up-your-environment Tue, 02 Oct 2018 13:03:02 GMT https://blogs.msdn.microsoft.com/sgern/?p=3615
  • Open https://www.microsoft.com/en-us/cloud-platform/enterprise-mobility-security-trial and click Sign-up for your free trial
    • Click on Create My account after filling out your Details
    • The next step will be Identity verification by phone. Fill in your details and choose between receiving a text message or a phone call for identification purposes.
    • Once this is done, we’re ready to go, so on this screen we will click on “You’re ready to go…”
     
    • Click the big green “Start free” button Sign in with the admin account you’ve just created in the previous steps, the .onmicrosoft.com account.
    • Next we’ll need verify the details in and submit the form.
    •  Step 2 takes us through Identity verification. Choose your preferred method, Text me or Call me, and finalize the verification step .
    • Step 3 asks for credit card details. Remember you won't be charged unless you upgrade
    • Step 4 is the final step, Click the checkbox and click "Sign up"
    And we’re done. In the next post we’ll go into configuring and preparing our Azure tenant further Ingmar Oosterhoff, Matthias Herfurth and Johannes Freundorfer  ]]>         INTUNE - Intune and Autopilot Part 1 - The Blueprint https://docs.microsoft.com/archive/blogs/sgern/intune-intune-and-autopilot-part-1-the-blueprint Mon, 17 Sep 2018 11:55:32 GMT https://blogs.msdn.microsoft.com/sgern/?p=3595 So why Azure, Intune and Autopilot? With Microsoft Intune and AutoPilot, the provisioning of devices got simplified. As you'll see during the course of these blog posts, the process and details will become more clearer. For the time being, you can think of Autopilot as an boxed deployment agent changing the way Windows 10 OOBE behaves. After the OOBE finished, the device will be an AzureAD joined machine with all the apps and configuration deployed to it.   The Shopping list For the different demos and features described in the following posts we'll need the following.
    • Azure Trial subscription
    • Intune trial subscription
    • Virtual Machine
    • Appx/MSIX package
      The blueprint Preparing the environment basically is a two step process:
    • Sign up to an Azure Tennant Trial
    • Configure Intune and Autopilot
    • Deploy your virtual machine
    Detaills
    • For this series of blogs we're utilizing the Intune 90 day trail and will guide you through all of the steps needed to start from scatch. After we present the default steps of implementation we'll go ahead and dig down deeper. If we miss something just leave us a comment.
      Matthias Herfurth, Johannes Freundorfer and Ingmar Oosterhoff]]>         App-V Sync not working if Device Guard is enabled https://docs.microsoft.com/archive/blogs/sgern/app-v-sync-not-working-since-if-device-guard-is-enabled Tue, 11 Sep 2018 07:34:48 GMT https://blogs.msdn.microsoft.com/sgern/?p=3575 With that Info we could identify what is happening. Finally we have a Fix Ready for the upcoming Rollups. Thanks Sebastian Gernert - Escalation Engineer App-V]]> MSIX - The MSIX Packaging Tool - Using the first package https://docs.microsoft.com/archive/blogs/sgern/msix-the-msix-packaging-tool-using-the-first-package Tue, 11 Sep 2018 07:24:55 GMT https://blogs.msdn.microsoft.com/sgern/?p=3515 previous blog post we created our first MSIX package, now it's finally time to  install the MSIX package, and launch the application! We will not go into the details of the different deployment scenario's. We'll leave that for a later blog post. Main goal is to install the package with a normal user account, and launch the application. Further posts will target different types of deployment scenarios and their implementation. To keep it super simple, once user is running Windows 10 build 17701 or later (Insider builds, currently), we can either use SMB or HTTP to get our package onto the machine for the user. So one way is to just locally double-click the MSIX package in some folder, or provide the package via a link on a website. Besides the package being accessible to the user, there are no further requirements to meet. User initiated web based deployment This scenario is based on a web service providing the users' with the MSIX packages. A bit of work, but once having the website in place, the user just needs to click on a link targeting the MSIX file. Afterwards the user opens the file to install te MSIX package. # User initiated file based deployment In this scenario easier than you properly expect. The user just needs to locate the file and execute it. This scenario doesn't need any administrative privileges or access Rights. Installing the MSIX package After the download or double-clicking of file, the default setup experience starts. The following dialog box appears This dialog highlights the name, publisher, package version and capabilities. This can all be defined during package creation. Due the fact MSIX being in preview the package icon is missing As the Checkbox "Launch when ready" indicates, the application will start after installation. This is the default behavior. Afterward, the user will have access to the application by selecting it in the start menu. Final note In the upcoming blog posts we'll dig down deeper into different deployment scenarios and have a closer look at package contents and creation. On a closing note for this post With the current Insider builds, the AppX PowerShell Commandlets work on MSIX packages as well. With the release of the updated set of commandlets we'll publish a follow-up with different examples using these commandlets to manage MSIX packages.   Johannes Freundorfer, Ingmar Oosterhoff and Matthias Herfurt]]> MSIX - The MSIX Packaging Tool - signing the MSIX package https://docs.microsoft.com/archive/blogs/sgern/msix-the-msix-packaging-tool-signing-the-msix-package Thu, 06 Sep 2018 13:58:02 GMT https://blogs.msdn.microsoft.com/sgern/?p=3495 Why should we sign packages? Signing code or binaries nowadays is common practice. Starting with executables, drivers and scripts code signing ensures source, integrity and alignment with release processes of the given code. Starting with Microsoft Store this was introduced into Windows as a requirement to deploy AppX successfully. Beside the use in production environments, during package creation and testing there are possibilities to bypass this requirement. We have 2.5   options:
    • Set up a CA in our test environment, and request a code signing certificate. All MSIX packages signed with this certificate can be installed on all computers in our environment (since they trust that CA)

    How to configure the PKI for code signing certificates:

    https://blogs.technet.microsoft.com/deploymentguys/2013/06/14/signing-windows-8-applications-using-an-internal-pki/ Since we got no test environment set up whatsoever, that would be the 0.5 option

    What to do when Focusing on AppX/MSIX there are four major scenarios present with different possibilities:
    • Packaging
    During packaging Codesigning can be bypassed via the Developer-Mode in Windows 10. https://docs.microsoft.com/en-us/windows/uwp/get-started/enable-your-device-for-development
    • Testing
    Developer-Mode will not help during package testing. Best would be to Test-Sign the package internally with your own PKI infrastructure or a Self-Signed Certificate:
    • Private Deployment
    Private Deployment means deployment only on company owned and managed devices. In this case code signing using your PKI infrastructure is perfectly fine and the most stable implementation.
    • Public Deployment
    Having a public deployment on an AppX/MSIX package most likely means uploading it to Microsoft Store. Only once you need to create a developer account for your company, which will give you access to the required upload area. During the process of final package checks the package will automatically get signed and all Windows 10 Clients will trust the resulting package.   Ingmar Oosterhoff, Johannes Freundorfer and Matthias Herfurth]]>