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.

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+"MUTEGAOutlookSignatureTemplatesOSignature.docx" #Path to the *.docx file, i.e "c:temptemplate.docx"
$Source = $env:appdata+"MutegaOutlookSignatureIMG"
$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 = 'MicrosoftSignatures'
$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:'SoftwareMicrosoftOffice14.0')
Remove-ItemProperty HKCU:'SoftwareMicrosoftOffice14.0CommonMailSettings' -Name 'ReplySignature'
Remove-ItemProperty HKCU:'SoftwareMicrosoftOffice14.0CommonMailSettings' -Name 'NewSignature'
Remove-ItemProperty HKCU:'SoftwareMicrosoftOffice14.0OutlookSetup' -Name 'First-Run'
If (Test-Path HKCU:'SoftwareMicrosoftOffice15.0')
Remove-ItemProperty HKCU:'SoftwareMicrosoftOffice15.0CommonMailSettings' -Name 'ReplySignature'
Remove-ItemProperty HKCU:'SoftwareMicrosoftOffice15.0CommonMailSettings' -Name 'NewSignature'
Remove-ItemProperty HKCU:'SoftwareMicrosoftOffice15.0OutlookSetup' -Name 'First-Run'
If (Test-Path HKCU:'SoftwareMicrosoftOffice16.0')
Remove-ItemProperty HKCU:'SoftwareMicrosoftOffice16.0CommonMailSettings' -Name 'ReplySignature'
Remove-ItemProperty HKCU:'SoftwareMicrosoftOffice16.0CommonMailSettings' -Name 'NewSignature'
Remove-ItemProperty HKCU:'SoftwareMicrosoftOffice16.0OutlookSetup' -Name 'First-Run'

#Office 2010
If (Test-Path HKCU:'SoftwareMicrosoftOffice14.0')
If ($ForceSignature -eq '1')
    Write-Output "Setting signature for Office 2010 as forced"
    New-ItemProperty HKCU:'SoftwareMicrosoftOffice14.0CommonMailSettings' -Name 'ReplySignature' -Value $SignatureName -PropertyType 'String' -Force
    New-ItemProperty HKCU:'SoftwareMicrosoftOffice14.0CommonMailSettings' -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:'SoftwareMicrosoftOffice15.0')
If ($ForceSignature -eq '1')
    Write-Output "Setting signature for Office 2013 as forced"
    New-ItemProperty HKCU:'SoftwareMicrosoftOffice15.0CommonMailSettings' -Name 'ReplySignature' -Value $SignatureName -PropertyType 'String' -Force
    New-ItemProperty HKCU:'SoftwareMicrosoftOffice15.0CommonMailSettings' -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:'SoftwareMicrosoftOffice16.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:'SoftwareMicrosoftOffice16.0CommonMailSettings') { } 
    Else { 
    New-ItemProperty HKCU:'SoftwareMicrosoftOffice16.0CommonMailSettings' -Name 'NewSignature' -Value $SignatureName -PropertyType 'String' -Force 
    If (Get-ItemProperty -Name 'ReplySignature' -Path HKCU:'SoftwareMicrosoftOffice16.0CommonMailSettings') { } 
    Else { 
    New-ItemProperty HKCU:'SoftwareMicrosoftOffice16.0CommonMailSettings' -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.localSysVolmutega.localscriptsOutlookSignature

Location of the logon file: \mutega.localSysVolmutega.localPolicies{xxxxx-xxxx-xxxxx-xxxxx}UserScriptsLogon

Location of the Outlook Signature of the Clients: %appdata%mutegaOutlooksignature

Final location of the Outlook Signature on the Clients: %appdata%MicrosoftSignatures

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%MicrosoftSignatures 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


Exchange 2010/2013 CU stuck at Languages install

This simple solution can save you a lot of time.

This issue can happen on the upgrade of Microsoft Exchange 2010 and  2013 when you apply a CU. The upgrade gets stuck at Languages, step 9, forever.

It turns out that the solution is very simple, this happens because System Center 2012 Endpoint Protection was installed on the server automatically by the SCCM, and this software uses the ”Same Engines” for Languages.


  1. Uninstall the Endpoint Protection on the server.

After uninstalling the Endpoint Protection, the Exchange update will continue.

When you do the upgrade of the Exchange CU finish, you can restart the server and install again the Endpoint Protection.

Hope this saves you some time!



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


Skype för Företag Lokal vs Skype för Företag Online (Office 365)

Nästan alla frågar samma sak, vilket är det bästa sättet att implementera Skype för Företag? vilket av följande 3 alternativ passar er bäst?

Implementera Skype för företag Värd, Lokal eller Office 365/Skype för Företag Online: det är frågan? </ strong>

Till att börja med är det viktigt att ta reda på vad som är företagets verkliga behov, och beroende på vad behoven är kan vi avgöra vad som krävs.

Enligt min mening, då ”jag gillar att ha kontroll och ha tillgång till alla funktioner” väljer jag Skype för företag Värd eller Lokal, men alla alternativ funkar naturligtvis lika bra.

Så vi kan ha följande implementerings scenarios:

  1. Skype för företag Värd eller Lokal
  2. Skype för Företag Värd/Lokal och Office365/Skype för Företag Online (Hybrid)
  3. Office 365
  4. Skype för företag Online

Jag kommer att försöka visa fördelar och nackdelar med alla tre alternativen.

Till att börja med finns, Skype för Företag Online och Office 365, online i molnet och är en billig lösning, men saknar funktioner som är viktiga för många organisationer.


Funktion Skype för företag som Värd eller på plats Lokalt 2015 Server Skype för Företag Online Plan 1 Skype för Företag Online Plan 2
Bra närvaro, direktmeddelanden (IM), Office Integration yes yes yes
Offentliga direktmeddelanden(IM) sammanslutning yes yes yes
ç yes yes yes
chat/ Chat-rum yes yes yes
Skype för Företag till Skype för Företag Samtal (Röst och Högupplöst Videosamtal) yes yes yes
Skill Search yes no no
Skrivbord, Application och Whiteboarddelning yes no yes
Grupp konferenser (Flerparts (3+)) A/V/Innehållsdelning yes no yes
Meeting Lobby Functionality yes no yes
Mötesanteckningar med OneNote Delning yes no yes
Skype för företag Audio Konferens yes no no
Integration med 3 part Audio Konferens Providers yes no yes
Skype för Företag flerpart Videosamtal yes no yes
Skype för Företag Enterprise Voice (VOIP/SIP Integration) yes no no
Skype för Företag Mobila Klienter yes yes yes
Skype för Företag Web App yes no yes

Skype för Företag Enterprise Voice (SIP Trunk)
Du måste ha en SIP Trunking tjänster kvalificerade för Skype för Business Server 2015, eller med en kvalificerad gateway.
Technical Differences

Feature Värd eller Lokal Skype för Företag Server 2015 Skype förr Företag Online Plan 1 Skype förr Förtag Online Plan 2
Åtkomst till CDR aoch QOE raw log files yes no no
Åtkomst till IM logs och Samtalsinspelning /logs. yes no no
Integrering av SIP & PSTN trunks yes no no
UCMA/UCWA/SDK integration yes no no
PowerShell access yes Partial Partial
Enhanced E911 (EV Only) yes no no
PBX Integrering yes no no

Datasäkerhet och sekretess

Skype för Företag online låter organisationerna distribuera mer hårdvara, hantera licenser och är väldigt lätt att få installerad, men var är datan lagrad och vilka har tillgång till den?

Så innan du implementerar Skype för Företag Online, måste du läsa Microsoft EULA noggrant. Microsoft har rätt till alla analyser, inklusive data som lagras på deras datacenter. Detta är också beroende av sekretesslagar i varje region. Men för dig är dessa data inte tillgängliga, så du har inte möjligheten att
att använda rapporteringsfunktionen och vara kompatibel.
Så vad är den bästa lösningen för dig?

Som jag sa tidigare, beror detta på vilka behov du har

Rekommenderad alternativ
Skype för Företag Online / Office 365 Värd/Lokal Skype för Företag
Tillgång till loggar och användardata Yes
Integrering med VOIP/SIP/PBX (SIP Trunk) Yes
Lokal värd Yes
Lokal epost-support Yes Yes
Lokal telefon-support Yes
API åtkomst Yes
Låg Kostnad Yes
Ingen hårdvara behövs Yes Yes
Grundserviceavtal Yes Yes
Omfattande SLA Yes

Du kan också titta på Klient jämförelsetabeller för Skype för Företag Server 2015 </ strong> (</ em> Dessa tabeller visar vilka funktioner som finns tillgängliga för Skype för företagsanvändare i en Lokal distribuering av Skype för Företag Server 2015. Samma funktioner är också tillgängliga för Skype för Företag Online och Office 365-användare om inget annat anges):


Alla alternativ Skype erbjuder för Företag är bra, så vill du ha det bästa alternativet för din organisation får du höra av dig. Vi utformar mer än gärna den bästa lösningen för dina behov


Hur du hittar sparade trådlösa lösenord i Windows

Följ dessa steg för att hitta ditt trådlös lösenord i Windows:

  1. Öppna en cmd med admins rättigheter och kör följande kommando för att se din trådlösa profiler:

    netsh wlan show profile

  2. Identifiera den trådlösa profilen som du vill ha lösenordet till och kör följande kommando:

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

    Du ser ditt Wi-Fi lösenord i fältet Key Content.
    Lycka till med att hitta ditt trådlösa lösenord

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}