When connecting to your Office 365 services, you might get the below error saying for any Msol cmdlet like new-msoluser, connect-msolservices and other.
The term 'Get-MsolUser' is not recognized as the name of a cmdlet
To fix this, download and install the Microsoft Online Services Sign-In Assistant for IT Professionals RTW which can be downloaded from this link.
After the installation you can check the installation of the assistant from your control panel. After that open a PowerShell window As Administrator and type.
Install-Module MSOnline -Force
Once done, enter the below
Sign in with your global admin account and presto!
After joining a computer to AzureAD you will login with a user and will be automatically added as a local admin. The trouble is when logging with other users. These users will automatically set as users to the computer. From the Computer Management Console there is no way to add an AzureAD as when you click on Add and Locations, there is no location for the AzureAD. If you look at the current AAD user in the Computer Management and Local Users and Groups you will find the current user as AZUREAD\noel.pulis.
Luckily there is a way to add an additional AzureAD user as a local admin.
– Open CMD (Command Prompt) as Admin
– Type NET Localgroup Administrators AzureAD\additionaluser /add
Once this is ready, open the Local Users and Groups and you will find the AzureAD user part of the local Administrators Group.
You will notice that the AzureAD Sync tool stopped synchronizing and in the Office 365 portal under Health Directory Sync Status you will notice the error message Warning: no recent synchronization under Password Sync.
In Powershell when you run the
Start-ADSyncSyncCycle you will get the below error
Warning: no recent synchronization
Start-ADSyncSyncCycle : System.InvalidOperationException: Scheduler is already
suspended via global parameters.
To fix this, simply open Powershell and run the below command.
Set-ADSyncScheduler -SchedulerSuspended $false
After it completes, re-run
Start-ADSyncSyncCycle and it will work.
When uploading files or PST files to Office 365 using AzCopy.exe, during the upload using Microsoft’s PST Import service you might have the frustrating error saying “
The client could not finish the operation within specified timeout“. On the command prompt it will be seen as stuck on saying 0 files uploaded with a transfer speed of 0 KB/s. I literally spent hours trying to find out why my PST files do not upload to Office 365.
This can be fixed by lowering the concurrent operations with the import services. After looking at the option which is
/NC option to either 2 or 1 depending on the internet connection upload speed. To be safe, in my case I have setup the NC as 1.
Here’s an example of how the command prompt will look like.
AzCopy.exe /source:\\My-Server\PST /dest:https://12345ab67cd89e0fg123h45.blob.core.windows.net/ingestiondata/Company/PST /destkey:jhdfasdfnasdnflasjkdfnjklsdanflasdfn/nfasdjkfnasdjklfnsjkladnfasjkldfnsdjklf== /S /V:d:\PST_Upload\upload.log /NC:1
When setting up your template and publishing your apps, if you setup a Group Policy Object (GPO) for your users, this does not work. After some research and testing I found out that to solve the issue, you must do the following:
Add the Explorer application to the Published apps
Start by publishing the command line interface (cmd.exe). In the Publishingtab, select cmd, and then click Publish > Publish program using path.
Enter the name of the app and the path. For our purpose, use “File Explorer” as the name and “%SYSTEMDRIVE%\windows\explorer.exe” as the path.
In my case this worked, hope it does for you.
You setup the domain, verified and you are in the process of configuring the Azure AD Connect Tool, you will be asked to enter the username and password for the tool to connect to the Azure AD.
The connector immediately stops with an error at the first step under the Express/Custom settings page titled “Connect to Azure AD” with the below error.
Unable to validate credentials. An unexpected error has occurred
This error most probably will show because you are using a user which ends with @outlook.com and the connect tool will not work with an service-bound Outlook username. To fix this issue and work successfully simply create a new ‘Global Admin’ user on the AD which ends @yourdomain.
In my case this worked like a charm.