Event ID 364 on the ADFS server – Encountered error during federation passive request. MSIS7042: The same client browser session has made ‘6’ requests in the last ‘4’ seconds

While configuring this, you might get multiple Multi Factor prompts, user performs MFA on-premises, but when redirected back to Azure AD – second factor prompt in cloud is presented. Here’s how you win:

Make sure you configure the federated domain setting in Azure AD with -SupportsMFA $true – this will point Multi Factor“requests” to the ADFS:

In addition to the above you also need to make sure to configure -PromptLoginBehavior Disabled, this will make sure that authentication requests from Azure AD will reach the ADFS “correctly” and won’t cause it to re-authenticate your users:

So you’ve purchased Microsoft’s Enterprise Mobility Suite (EMS) licenses, now you need to assign them to users within your organization. A typical situation will be that you already have Office 365 licensed users, and it make sense that all of them will get EMS licenses too.

To achieve this, I would suggest using an Azure AD group with Dynamic Group membership. in this example, the group will include accounts that match ALL these conditions:

There are some known limitation and inconsistency with user photos synchronization from Active Directory (using the thumbnailPhoto attribute) to Azure AD and Office 365 apps: Exchange, SharePoint and Skype for Business (aka Lync), specifically if you want to upload high resolution photos of your users that will span across all of Office 365 services.

After spending some research time around this issue, here are my findings:

The Active Directory thumbnailPhoto attribute value is limited to about 100KB in size – this will mostly prevent you from uploading a “high resolution” photo

“Common knowledge” around synchronizing the thumbnailPhoto using Directory Synchronization (aka DirSync / AAD Sync/ AAD Connect) to Office 365 / Azure AD is that the attribute should not exceed 10KB, and the recommended photo dimension is 96 x 96 pixels – This is really an “Exchange” limit as far as I know..

When User Photos are stored within Office 365 a web service handles requests for the photo with predefined allowed sizes for example – https://outlook.office365.com/owa/service.svc/s/GetPersonaPhoto?email=emailaddress@domain.com&size=HR648x648

Modify this to your email address to try this out

There are quite a few possible sizes, try for example 96×96 and 240×240 to get the idea

SharePoint holds a separate location and also a few versions for it’s images within each users profile folder and is suppose to synchronize those from Exchange Web Services

The Set-UserPhoto cmdlet from Exchange (Online and On-Prem) allows you to save high resolution photos, and integrates with Skype for Business Server 2015 (also for Lync 2013) and SharePoint 2013/2016 – each product with it’s own flow which I’m not going into explaining.

So to summarize at this point, we want to import high resolution photos to our users. If we rely on the thumbnailPhoto attribute value from Active Directory, we will end up with low resolution images (needs more JPEG effect) or inconsistent results if we look on the SharePoint case.

To upload high resolution photos to Office 365, you should use Set-UserPhoto. This approach works great for Exchange Online, Skype for Business and Azure AD. Although promising, my testing (and others..) showed that if your users’ photos were previously synced to SharePoint Online – they will not necessarily be updated using this method.

Just a quick note for everyone missing the log files location of Microsoft Intune On-Premises Exchange Connector, seems like there is no documentation on where those files exists. and they are very useful for debugging this component.

This info came from a support case I’ve had with the on-premises connector 🙂

If the module is not well-formed and its location is not included in the value of the PSModulePath environment variable, basic discovery features of Windows PowerShell, such as the following, do not work.

The ListAvailable parameter of the Get-Module cmdlet cannot find the module.

The Import-Module cmdlet cannot find the module. To import the module, you must provide the full path to the root module file or module manifest file.

In my case, I’ve noticed that because I did not modified the PSModulePath system variable, a schedule task of the PowerShell script using that module failed to import the module…. the fun part was that running it in Interactive Mode (while being logged in to the server) actually worked…

The MSILOG indeed showed that the setup was looking for the RTM language files in the original location where the setup files were, but they are long gone… with the RTM DVD no where to be-found (RTM trial files + the oldest Language Pack bundle are in a non compatible version) this situation was doomed to failure.

So, I’ve turned to manually remove any references to the Client / Server language packs on the server, this included removing a whole bunch of registry keys:

And it works ! Now, I guess that with a script this would have been much quicker then the registry method, but at least now I’m (and you are) aware of this workaround , and here’s the script for your usage:

** edit the $setuplocation variable for your directory of the servicepack.

Following a troubleshooting session I’ve had lately, I wanted to share with you an important recommended settings that most folks (myself included) often overlook.

With more and more virtual servers and less and less physical servers being deployed, capabilities like SpeedStep of a CPU were forgotten. Take for example the following “modest” specifications of Intel Xeon E5-2690 v2, with 10 cores @ 3.0 GHz this is a “fare” spec for a high load / CPU intensive profile server.

BUT ! if you forget to select the “High Performance” power option in Windows Server for example, you could end up with:

Notice that the speed of the CPU is less the half the speed it can run at. now to make things better, just make sure to select the “preferred” settings for your busy server:

Just a heads up for all you folks out there, the default “Balanced” option caused a performance issue with an Exchange 2013 server that was running on this physical hardware and once the option was changed – all was back to normal 🙂