How to Package and Deploy Windows Applications with Intune

You cannot just upload your app’s installation file directly to Intune, it must be packaged using a small command-line tool: the IntuneWinAppUtil.  This archives and compresses the installation to a .intunewim file, and that’s what you upload.

This post will guide you through the process of getting your Win32 app ready for Intune upload (packaging) and configuring it for client installation (deploying)


Win32 applications are your traditional Executable/MSI apps which are then wrapped into intunewin format using the Win32AppGui tool from Microsoft.

Folder Layout

I’ve created this folder layout:

One thing to note here is that the packaging tool will grab every file in the Source directory you point it to, so make sure that folder only has source files in it.

 The 7zip folder is where the installer is.

The Intunewin folder is where we will store the Intunewin file.

Packaging the app

In the example for this post, I’ll be working with 7-Zip.  This only has one file, but if your app installer has multiple files (e.g. subfolders), that is supported too.

  1. Place your installation file(s) in a dedicated folder.  The entire contents of this folder will be archived, so make sure it includes everything you need, but nothing more.
  2. From the command prompt, run IntuneWinAppUtil.exe, which is the Win32 Content Prep Tool.  In the command prompt window, you are prompted for four pieces of info:
  • The source folder (created above)
  • The setup file (the file that begins app installation when executed)
  • An output folder (where the .intunewim file is saved)
  • Whether or not you need to specify a catalog folder (only needed if deploying to Windows 10 S mode)

After you complete the last prompt, a stream of output will fill the screen; the last line reporting the app has been packaged.

Deploying the app

  1. Navigate to Intune Admin Portal and then select Apps > Windows > Add:

2. Choose the app type Windows app (Win32) and click Select:

3. Select your Intunewin file and Ok:

4. Populate any fields on this page. You can also add your icon at the bottom to appear in Company Portal and click Next:

5. On the Program page, you need to enter install and uninstall commands for your app.  If you uploaded an MSI file, these are usually prepopulated for you by Intune using the msiexec parameters to do both actions silently. 

The install behavior is a key option to get right.  Generally, you want to choose System, as this executes the installation with administrative rights.  However, there may be circumstances you need to execute in the user context. Click  Next:

6. Add any app requirements (64-bit for example). I also usually add the earliest supported Windows OS version here, we don’t want unsupported versions. Click  Next:

7. For Intune to know whether or not the app is installed, you need to include detection rules. These are mandatory because, without them, Intune wouldn’t know when to stop trying to install the app, or how to report success/failure. Use the manually configure detection rules and use the MSI rule type.  This queries the MSI product code, which for MSIs is a unique identifier for the app.  For MSI uploads, it’s populated automatically.Click Ok and Next:

8. Dependencies – If the application requires something else to be installed first, add that here. You can also specify whether to force an install if it is missing. Click Next:

9. The next screen gives Supersedence options. If this is an updated application, select the previous version and you can tell it whether to in-place upgrade or remove and re-install. Click Next:

10. Here, we will deploy the app using Intune by assigning them to All Users group. You can choose how you want to assign the app to users and devices, and there are three options:

  • Required: The app is installed on devices in the selected groups.
  • Available for enrolled devices: Users install apps from the Company Portal app or the Company Portal website.
  • Uninstall: The app is uninstalled from devices in the selected groups.

From the above list of options, select Available for enrolled devices and add the group, because we want the app to be available for installation in Company Portal. Click Next:

11. On the final page for review + create, you can confirm the settings you’ve entered.  Hitting create will then upload the application. 

After some time, the Company Portal will be installed on your devices:

Deploy the Company Portal with Intune

The company portal is an essential app you should deploy on the devices you want to manage with Intune. With the Company Portal users can securely access their company apps and data, install or reinstall applications, check if the device meets compliance and more. Here are a few steps on how to deploy the Company Portal App from the Microsoft Store app (new) with Intune. 

The company portal can be installed on Windows 10/11, macOS, Android and iOS, but I will cover the Windows deployment in this post.

Deploy the App

  1. Sign in to the Intune portal with an account that has an Intune role assigned with the permission to deploy an App.
    Your account should have one of the following Intune roles assigned:
  • Intune Administrator
  • Application Manager

2. Select Apps All Apps > +Add

3. Select Microsoft Store app (New) and Click Select

4. Select Search the Microsoft Store app (New)

5. Search for Company Portal > Select Company Portal > Click Select

6. Change the App information as needed. I changed the Install behavior from User to System because I want to deploy the app to all users. I also added the category ProductivityClick Next when you are done changing the information of the App.

7. Now assign the App to the device or user groups you want. Like I said I want the Company Portal to be deployed to All Users. So I selected All Users with a Required deployment. Select Next.

8. Review the App settings and after reviewing select Create.

After some time the Company Portal will be installed on your devices:

Powershell – Folders Permissions Report

$FolderPath = Get-ChildItem -Directory -Path "C:\temp" -Recurse -Force
$Output = @()
ForEach ($Folder in $FolderPath) {
    $Acl = Get-Acl -Path $Folder.FullName
    ForEach ($Access in $Acl.Access) {
$Properties = [ordered]@{'Folder Name'=$Folder.FullName;'Group/User'=$Access.IdentityReference;'Permissions'=$Access.FileSystemRights;'Inherited'=$Access.IsInherited}
$Output += New-Object -TypeName PSObject -Property $Properties            
$Output | Export-CSV C:\temp\permissions.csv -Encoding UTF8

Exchange 2013 DAG CU19 Upgrade

Here is the step that I will do to upgrade the Exchange 2013 to CU19, with the new .NET Framework 4.7.1.

Exchange 2013 has a different servicing strategy than Exchange 2007/2010 and utilises Cumulative Updates (CUs) rather than the Rollup Updates (RU/UR) which were used previously. CUs are a complete installation of Exchange 2013 and can be used to install a fresh server or to update a previously installed one. Exchange 2013 SP1 was in effect CU4, and CU18 is the fourteenth post SP1 release. Updating from any CU to any CU is supported, however to the best of my knowledge Microsoft only tests updates from N-2 builds. For example, when Microsoft released CU19, they would test the update process from CU17 and CU18 as they were the previously supported builds. It means that when we are updating from CU10 to CU19, it’s possible that we will encounter some problem that Microsoft has not identified in their testing. Although that risk exists, in my opinion, it has diminished over time as the quality of the Exchange 2016/2013 code has improved. Microsoft best practices are to keep the Exchange upgrade with the two last version available, so now we should have been at CU17 or CU18, but since we are not, the best approach, in my opinion, is go directly to CU19.

After the Exchange 2013 CU16 the .NET 4.6.2 is a requirement, and to make a smooth transition, the CU15 was working with .NET 4.6.1 and .NET 4.6.2, so we could upgrade the .NET without getting big downtimes.

Since the CU15 is no longer available the bridge has washed out, so we need to upgrade the .NET first and then the Exchange.

How to Upgrade from Exchange 2013 CU10 to CU19 on DAG Members

  1. Backup/Snapshot of all Server
  2. I will check if the databases are healthy (Check the links below for more information about this step)
  3. Put one node in Maintenance mode (Check the links below for more information about this step)
  4. Reboot the Server
  5. Install .Net 4.7.1
  6. Reboot the Server
  7. Disable the Antivirus
  8. Install the CU19 (This step will take between 1 hour to 2 hours) – Note: We need to make sure there is disk space available, it makes sense to extract the CU to another drive than C: drive.
  9. Reboot the server after the successful CU installation.
  10. Wait a few minutes for the servers to get sorted, and check if the databases are healthy (Check the links below for more information about this step)
  11. Remove the server from Maintenance mode (Check the links below for more information about this step)
  12. Re-check if the databases are healthy (Check the links below for more information about this step)
  13. Repeat the same steps to update the Other DAG member

More information for the Steps 2,3,10,11 and 12 on this links below:


Simple instruction:

Installation failure recovery

Experience will show whether this is a major concern or not. Update rollups are usually able to roll back seamlessly if they encounter an error. Whether the cumulative update failed installation recovery process becomes a burden or not, only time will tell.

Some Items for Consideration

  • Make a full backup of the Exchange servers
  • The customs customisations can be lost, especially on the OWA
  • Third-party software integrations

Exchange .NET Framework Support Table

I believe that is all, the important things that we need to think about, off course, Microsoft have made it much simple the Exchange upgrades, and normally this runs smoothly, but be sure that you have a full backup of the servers.

Best of luck and hope this can help you.

Server “Online – Performance Counters not started” Windows Server

If you have the following message, Performance counters not started, on the Server Manager on All Servers menu.

The solution is simple:

  1. Right Click on the Server Name
  2. Click on Start Performance Counters


How to find saved wireless passwords on your Windows

To find saved wireless password on your windows, please follow this steps:

  1. Open a cmd with admins rights and run the following command to see your wireless profiles:

    netsh wlan show profile

  2. Identify the wireless profile that you want to get the password, and run the following command:

    netsh wlan show profile “WIRELESS PROFILE NAME” key=clear

    You’ll see your Wi-Fi password in the Key Content field.

    Good luck with finding out your wireless password.

Script to set Outlook signature using AD info, Security Groups and Templates

Script to set Outlook e-mail signature using Active Directory information, Security groups and unlimited templates.

Script Localization: 

    Script to set Outlook 2010/2013/2016 e-mail signature using Active Directory information, Security groups and unlimited templates
    This script will set the Outlook 2010/2013/2016 e-mail signature on the local client using Active Directory information. 
    The template is created with a Word document, where images can be inserted and AD values can be provided.

    Author: João Dias
	Company: Mutega IT AB
    Version 1.0
	Script it is a mix of Jan Egil Ring and Daniel Classon Script

    All scripts and other powershell references are offered AS IS with no warranty.
    These script and functions are tested in my environment and it is recommended that you test these scripts in a test environment before using in your production environment.

#Custom variables
$SignatureName = 'OSignature' #insert the company name (no spaces) - could be signature name if more than one sig needed
$SigSource = $env:appdata+"\MUTEGA\OutlookSignature\Templates\OSignature.docx" #Path to the *.docx file, i.e "c:\temp\template.docx"
$Source = $env:appdata+"\Mutega\OutlookSignature\IMG\"
$SignatureVersion = "1.0" #Change this if you have updated the signature. If you do not change it, the script will quit after checking for the version already on the machine
$ForceSignature = '1' #Set to 1 if you don't want the users to be able to change signature in Outlook
#Environment variables
$AppData=(Get-Item env:appdata).value
$SigPath = '\Microsoft\Signatures'
$LocalSignaturePath = $AppData+$SigPath
$RemoteSignaturePathFull = $SigSource

<# #Copy version file
If (-not(Test-Path -Path $LocalSignaturePath\$SignatureVersion))
New-Item -Path $LocalSignaturePath\$SignatureVersion -ItemType Directory
Elseif (Test-Path -Path $LocalSignaturePath\$SignatureVersion)
Write-Output "Latest signature already exists"
}  #>

#Check signature path (needs to be created if a signature has never been created for the profile
if (-not(Test-Path -path $LocalSignaturePath)) {
	New-Item $LocalSignaturePath -Type Directory

#Get Active Directory information for current user
$UserName = $env:username
$Filter = "(&(objectCategory=User)(samAccountName=$UserName))"
$Searcher = New-Object System.DirectoryServices.DirectorySearcher
$Searcher.Filter = $Filter
$ADUserPath = $Searcher.FindOne()
$ADUser = $ADUserPath.GetDirectoryEntry()
$ADDisplayName = $ADUser.DisplayName
$ADEmailAddress = $ADUser.mail
$ADTitle = $ADUser.title
$ADDescription = $ADUser.description
$ADTelePhoneNumber = $ADUser.TelephoneNumber
$ADMobile = $
$ADStreetAddress = $ADUser.streetaddress
$ADwWWHomePage = $ADUser.wWWHomePage
$ADCity = $ADUser.l
<# $ADCustomAttribute1 = $ADUser.extensionAttribute1 #>
$ADModify = $ADUser.whenChanged

#Copy signature templates from source to local Signature-folder
Write-Output "Copying Signatures"
Copy-Item "$Sigsource" $LocalSignaturePath -Recurse -Force
$ReplaceAll = 2
$FindContinue = 1
$MatchCase = $False
$MatchWholeWord = $True
$MatchWildcards = $False
$MatchSoundsLike = $False
$MatchAllWordForms = $False
$Forward = $True
$Wrap = $FindContinue
$Format = $False
#Insert variables from Active Directory to rtf signature-file
$MSWord = New-Object -ComObject word.application
$fullPath = $LocalSignaturePath+'\'+$SignatureName+'.docx'

#User Name $ Designation 
$FindText = "DisplayName"
$Designation = $ADCustomAttribute1.ToString()

#Designations in Exchange custom attribute 1
If ($Designation -ne '') { 
	$Name = $ADDisplayName.ToString()
	$ReplaceText = $Name+', '+$Designation
Else {
	$ReplaceText = $ADDisplayName.ToString() 
$MSWord.Selection.Find.Execute($FindText, $MatchCase, $MatchWholeWord,	$MatchWildcards, $MatchSoundsLike, $MatchAllWordForms, $Forward, $Wrap,	$Format, $ReplaceText, $ReplaceAll	) 

$FindText = "DisplayName"
$ReplaceText = $ADDisplayName.ToString() 
$MSWord.Selection.Find.Execute($FindText, $MatchCase, $MatchWholeWord,	$MatchWildcards, $MatchSoundsLike, $MatchAllWordForms, $Forward, $Wrap,	$Format, $ReplaceText, $ReplaceAll	)
$FindText = "Title"
$ReplaceText = $ADTitle.ToString()
$MSWord.Selection.Find.Execute($FindText, $MatchCase, $MatchWholeWord,	$MatchWildcards, $MatchSoundsLike, $MatchAllWordForms, $Forward, $Wrap,	$Format, $ReplaceText, $ReplaceAll	)
   If ($ADDescription -ne '') { 
   	$FindText = "Description"
   	$ReplaceText = $ADDescription.ToString()
Else {
	$FindText = " | Description "
   	$ReplaceText = "".ToString()
$MSWord.Selection.Find.Execute($FindText, $MatchCase, $MatchWholeWord,	$MatchWildcards, $MatchSoundsLike, $MatchAllWordForms, $Forward, $Wrap,	$Format, $ReplaceText, $ReplaceAll	)
#$LogInfo += $NL+'Description: '+$ReplaceText
#Street Address
If ($ADStreetAddress -ne '') { 
       $FindText = "StreetAddress"
    $ReplaceText = $ADStreetAddress.ToString()
   Else {
    $FindText = "StreetAddress"
    $ReplaceText = $DefaultAddress
	$MSWord.Selection.Find.Execute($FindText, $MatchCase, $MatchWholeWord,	$MatchWildcards, $MatchSoundsLike, $MatchAllWordForms, $Forward, $Wrap,	$Format, $ReplaceText, $ReplaceAll	)

If ($ADCity -ne '') { 
    $FindText = "City"
       $ReplaceText = $ADCity.ToString()
   Else {
    $FindText = "City"
    $ReplaceText = $DefaultCity 
$MSWord.Selection.Find.Execute($FindText, $MatchCase, $MatchWholeWord,	$MatchWildcards, $MatchSoundsLike, $MatchAllWordForms, $Forward, $Wrap,	$Format, $ReplaceText, $ReplaceAll	)
If ($ADTelephoneNumber -ne "") { 
	$FindText = "TelephoneNumber"
	$ReplaceText = $ADTelephoneNumber.ToString()
Else {
	$FindText = "TelephoneNumber"
    $ReplaceText = $DefaultTelephone
$MSWord.Selection.Find.Execute($FindText, $MatchCase, $MatchWholeWord,	$MatchWildcards, $MatchSoundsLike, $MatchAllWordForms, $Forward, $Wrap,	$Format, $ReplaceText, $ReplaceAll	)
If ($ADMobile -ne "") { 
	$FindText = "MobileNumber"
	$ReplaceText = $ADMobile.ToString()
Else {
	$FindText = "| Mob MobileNumber "
    $ReplaceText = "".ToString()
$MSWord.Selection.Find.Execute($FindText, $MatchCase, $MatchWholeWord,	$MatchWildcards, $MatchSoundsLike, $MatchAllWordForms, $Forward, $Wrap,	$Format, $ReplaceText, $ReplaceAll	)

$MSWord.ActiveDocument.Hyperlinks.Add($MSWord.Selection.Range, “mailto:”+$ADEmailAddress.ToString(), $missing, $missing, $ADEmailAddress.ToString()) 

$selection = $MSword.selection
$selectimage = $selection.InlineShapes.AddPicture($Source+"\linkedinbutton.jpg")

#Save new message signature 
Write-Output "Saving signatures"

#Fixes Enumeration Problems
$wdTypes = Add-Type -AssemblyName 'Microsoft.Office.Interop.Word' -Passthru
$wdSaveFormat = $wdTypes | Where {$_.Name -eq "wdSaveFormat"}

#Save HTML
$path = $LocalSignaturePath+'\'+$SignatureName+".htm"
$MSWord.ActiveDocument.saveas([ref]$path, [ref]$wdSaveFormat::wdFormatHTML);
$MSWord.ActiveDocument.saveas($path, $wdSaveFormat::wdFormatHTML);
#Save RTF 
$path = $LocalSignaturePath+'\'+$SignatureName+".rtf"
$MSWord.ActiveDocument.SaveAs([ref]$path, [ref]$wdSaveFormat::wdFormatRTF);
$MSWord.ActiveDocument.SaveAs($path, $wdSaveFormat::wdFormatRTF);
#Save TXT    
$path = $LocalSignaturePath+'\'+$SignatureName+".txt"
$MSWord.ActiveDocument.SaveAs([ref]$path, [ref]$wdSaveFormat::wdFormatUnicodeText);
$MSWord.ActiveDocument.SaveAs($path, $wdSaveFormat::wdFormatUnicodeText);

#Remove old regedit keys
If (Test-Path HKCU:'\Software\Microsoft\Office\14.0')
Remove-ItemProperty HKCU:'\Software\Microsoft\Office\14.0\Common\MailSettings' -Name 'ReplySignature'
Remove-ItemProperty HKCU:'\Software\Microsoft\Office\14.0\Common\MailSettings' -Name 'NewSignature'
Remove-ItemProperty HKCU:'\Software\Microsoft\Office\14.0\Outlook\Setup' -Name 'First-Run'
If (Test-Path HKCU:'\Software\Microsoft\Office\15.0')
Remove-ItemProperty HKCU:'\Software\Microsoft\Office\15.0\Common\MailSettings' -Name 'ReplySignature'
Remove-ItemProperty HKCU:'\Software\Microsoft\Office\15.0\Common\MailSettings' -Name 'NewSignature'
Remove-ItemProperty HKCU:'\Software\Microsoft\Office\15.0\Outlook\Setup' -Name 'First-Run'
If (Test-Path HKCU:'\Software\Microsoft\Office\16.0')
Remove-ItemProperty HKCU:'\Software\Microsoft\Office\16.0\Common\MailSettings' -Name 'ReplySignature'
Remove-ItemProperty HKCU:'\Software\Microsoft\Office\16.0\Common\MailSettings' -Name 'NewSignature'
Remove-ItemProperty HKCU:'\Software\Microsoft\Office\16.0\Outlook\Setup' -Name 'First-Run'

#Office 2010
If (Test-Path HKCU:'\Software\Microsoft\Office\14.0')
If ($ForceSignature -eq '1')
    Write-Output "Setting signature for Office 2010 as forced"
    New-ItemProperty HKCU:'\Software\Microsoft\Office\14.0\Common\MailSettings' -Name 'ReplySignature' -Value $SignatureName -PropertyType 'String' -Force
    New-ItemProperty HKCU:'\Software\Microsoft\Office\14.0\Common\MailSettings' -Name 'NewSignature' -Value $SignatureName -PropertyType 'String' -Force
Write-Output "Setting Office 2010 signature as available"

$MSWord = New-Object -comobject word.application
$EmailOptions = $MSWord.EmailOptions
$EmailSignature = $EmailOptions.EmailSignature
$EmailSignatureEntries = $EmailSignature.EmailSignatureEntries


#Office 2013
If (Test-Path HKCU:'\Software\Microsoft\Office\15.0')
If ($ForceSignature -eq '1')
    Write-Output "Setting signature for Office 2013 as forced"
    New-ItemProperty HKCU:'\Software\Microsoft\Office\15.0\Common\MailSettings' -Name 'ReplySignature' -Value $SignatureName -PropertyType 'String' -Force
    New-ItemProperty HKCU:'\Software\Microsoft\Office\15.0\Common\MailSettings' -Name 'NewSignature' -Value $SignatureName -PropertyType 'String' -Force
Write-Output "Setting Office 2013 signature as available"

$MSWord = New-Object -comobject word.application
$EmailOptions = $MSWord.EmailOptions
$EmailSignature = $EmailOptions.EmailSignature
$EmailSignatureEntries = $EmailSignature.EmailSignatureEntries


#Office 2016 signature

If (Test-Path HKCU:'Software\Microsoft\Office\16.0')

Write-Output "Setting signature for Office 2016"

If ($ForceSignature -eq '1')

Write-Output "Setting Office 2016 as available"

$MSWord = New-Object -ComObject word.application
$EmailOptions = $MSWord.EmailOptions
$EmailSignature = $EmailOptions.EmailSignature
$EmailSignatureEntries = $EmailSignature.EmailSignatureEntries


If ($ForceSignature -eq '1')
Write-Output "Setting signature for Office 2016 as forced"
    If (Get-ItemProperty -Name 'NewSignature' -Path HKCU:'\Software\Microsoft\Office\16.0\Common\MailSettings') { } 
    Else { 
    New-ItemProperty HKCU:'\Software\Microsoft\Office\16.0\Common\MailSettings' -Name 'NewSignature' -Value $SignatureName -PropertyType 'String' -Force 
    If (Get-ItemProperty -Name 'ReplySignature' -Path HKCU:'\Software\Microsoft\Office\16.0\Common\MailSettings') { } 
    Else { 
    New-ItemProperty HKCU:'\Software\Microsoft\Office\16.0\Common\MailSettings' -Name 'ReplySignature' -Value $SignatureName -PropertyType 'String' -Force

taskkill /F /IM winword.exe


User Groups

Name Description Type
OSIGADMIN Outlook Signature Admin Group Security Group – Global
MTSE001 User Outlook Signature Template in Swedish without Mobile Number Security Group – Global
MTSE002 User Outlook Signature Template in Swedish with the Mobile Number Security Group – Global

Nomeclature for Creation of User Groups




SE = Swedish

001 = Template number 001

The security group and the template .docx must have the same name, as I should describe further on.

Active Directory Fields

The Outlook Signature gets the information from the Active Directory, so we need to fill up the following fields.

AD Fields







Outlook Signature localization (Example)

Location of the script files: \\mutega.local\SysVol\mutega.local\scripts\OutlookSignature

Location of the logon file: \\mutega.local\SysVol\mutega.local\Policies\{xxxxx-xxxx-xxxxx-xxxxx}\User\Scripts\Logon

Location of the Outlook Signature of the Clients: %appdata%\mutega\Outlooksignature

Final location of the Outlook Signature on the Clients: %appdata%\Microsoft\Signatures

Outlook e-mail Signature GPO

This GPO is the one responsible to run Outlook Signature script at the Log On.

Name of the GPO: OutlookSignature

Fuction: Running the file Run_LO.cmd for the users that below to the Outlook Signature Security Group.

Outlook Signature Execution

The Outlook signature runs allow on the Logon, but the execution only occurs in the following conditions:

  1. The version of the Signature is not the same;
  2. The user is added to an Outlook Signature security group;
  3. The user is changed to a new Outlook Signature security group to another one;
  4. The Signature file under %appdata%\Microsoft\Signatures is deleted manually.

Outlook Signature Desktop Icon

Now the user has the possibility to recreate the Outlook Signature.

  1. The shortcut is called ReCreate Outlook Signature, and if the end-user double clicks it, will recreate the Outlook Signature


Script – Migration of mailboxes from Exchange On-premise to Exchange Online

If you want to perform a bulk migration of mailboxes from Exchange On-premise to Exchange Online, this PowerShell script will help you.

You just need to create a txt file with the alias mailboxes that you want to migrate. The script will migrate all the alias mailboxes on the txt to Office 365 (Exchange Online).

This is tested on an Exchange 2010 Hybrid environment but should work also on the new Exchange version.

Script localization: 


# Migration of mailboxes from Exchange On-premise to Exchange Online 
# Written by João Dias  
# Date 28/03/2017 
# Version: 1.0 
#Set Powershell Execution Policy to Unrestricted 
Set-ExecutionPolicy Unrestricted -Force 
#Get credentials 
$O365CREDS = Get-Credential 
$ONPREMCREDS = Get-Credential 
#Configuring Session 
$SESSION = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $O365CREDS -Authentication Basic -AllowRedirection 
#Import Exchange Online Session 
Import-PSSession $SESSION 
#Connect to Exchange Online 
Connect-MsolService -Credential $O365CREDS 
#Reading the user list that will be migrated to O365 
$MAILBOXLIST = Get-Content "C:\temp\Userlist.txt" 
#Migration of mailboxes to O365 
foreach ($line in $MAILBOXLIST) {New-MoveRequest -Identity $line.alias -Remote -RemoteHostName -TargetDeliveryDomain -RemoteCredential $ONPREMCREDS -BadItemLimit 1000}

Troubleshoot Outlook performance issues – Exchange/Office 365

It is not the first, and it will not be the last client that ask me what to do to fix Outlook performance issues.

Dennis from has written an article that mirrors what I usually recommend to my customers.

Here it is Dennis fantastic post. To see the original post click here.


Windows 2016 or Windows 10 fail to perform an in-place upgrade

When performing a Windows Server 2012 in-place upgrade to Windows Server 2016, and you get an error pops up saying just that the upgrade has failed, the first thing to do is look at the logs.

Location of the Windows Server 2016 in-place upgrade: C:\$Windows.~BT\Sources\panther\setupact.log

More info regarding log files that are created when you upgrade to a new version of Windows:

If you got these two errors below, we have the solution for you.

Error    MOUPG CDlpActionProductKeyValidate::ReportDownlevelInstallChannel(2896): Result = 0x80070490[gle=0x00000002]

Error    MOUPG ProductKey: Failed to report Host OS channel to telemetry.[gle=0x00000002]

The system was not able to mount the WIM file, so what can be preventing this to happen?

A filter driver could be causing this error. To find the filter driver, run this:

fltmc filters

CBFLTFS4 is a CallBackFilter develped by Eldos.

According to Eldos:
Callback File System (CBFS) lets you create virtual file systems and disks that expose and manage remote data as if these data were files on the local disk.

Callback File System is an SDK (software development kit, a component for use in software development) for Windows® platform.

We have it in our remote application host server because we have installed Liquidware Labs’ ProfileUnity.

We need to temporarily disable this filter driver.

  1. In order to do that we need to change the registry key:

    Value: Start
    Type: REG_DWORD
    To: 4

  2. Restart the machine

You can also run this command line:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\cbfltfs4 /v Start /t REG_DWORD /d 4 /f

Enable Startup automatically (To run after the machine is upgraded)

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\cbfltfs4 /v Start /t REG_DWORD /d 0 /f

Reference: Charlie Chang Blog