Marc Lognoul

Relentless cloud professional. Restless rider. Happy husband. Proud father. Opinions are my own.


Leave a comment

Office 365: Small FAQ over PowerShell with Authentication, Authorization and Delegation

Can I use PowerShell with Multi-Factore Authentication (MFA) with PowerShell

No. The account used for administration may cannot have MFA enabled. Obvsisouly this does not apply to the other (admin or standard) users when consuming the service or the Admin Center

Can I use Prowershell while I am not Tenant/Global Admin (aka MSOL…)

Yes. Thanks to the admin roles, MS Online Cmdlet can be used against a restricted set of functions deriving from the role’s scope of responsabilities. Detailed role definition: Assigning admin roles in Office 365.

Note: At writing time, the MS online documentation is still not up-to-date and often incorrectly states than global admin privilege is required for most of actions…

Can I administer multiple tenants from the same account?

Yes (but…). While the concept of “uber” admin does exist under the forme of the Delegated Administrator, it is intended for Partners to administer customer’s tenants. To enable it, the tenant must be linked to an approved Partner. Refer to this procedure for the détails.

Then, the approved partner must connect to the service using his/her account and recuperate the customer’s tenant’s unique identifier

$TenantGUID =(Get-MSOlPartnerContract -domain

In the command above, is the DNS domain linked to the customer’s tenant. As stated above, this the Cmdlet Get-MSOlPartnerContract is only eligible to approved patners

For every action, the tenant unique identifier must be provided by mean of the -TenantId parameter:

Get-MsolUser -TenantID $TenantGUID

Do I need to be Tenant/Global Admin to interact with SharePoint Online site content or Exchange Online mailbox items?

It depends. While setting up users, permissions, sites and so on do require higher privilèges, interacting with SharePoint or Exchange content can be achieved with standard user permission using the CSOM (SharePoint) or the EWS (Exchange). I will cover this topic more in depth in a coming post.


Leave a comment

Office 365: Setting-up DNS Records on

While Office 365 online documentation covers the set-up for a broad range of DNS providers, I recently performed set-up on the DNS manager provided by coupled to their commercial offer. While this scenario is not covered (yet) by Microsoft documentation it is fully functional.

As reminder, the following record types are currently required to operate your Office 365 tenant properly:

  • TXT record for verification
  • TXT record for spam protection
  • MX record for mail routing
  • CNAME records for various purposes
  • SRV records for Skype for Business

While supports all the necessary record types, you will not be able to control their Time to Live and the configuration of SRV records is a little complex. Therefore, here is a quick drawing in order to map correctly information from your tenant to the form.


No need to worry about the non-configurable TTL, it is set to 3600 which fulfills the Office 365 requirement.

As usual with DNS, it may take from minutes to hour for the changes you applied at your DNS host to propagate to other DNS servers. Therefore, you might have to wait a while before Office 365 Admin Center considers your set-up as valid.

More Information


SharePoint 2013: Stretched Farm vs. DRP Farm and Everything Related


In my previous post I published my comments over Serge Luca’s view on Stretched Farms and their prerequisites. In this one, I will discuss the concept of Stretched Farm itself and compare it to DRP Farm.

It is often said that Stretched Farms are the (almost) perfect solution to both High Availability and Disaster Recover requirements. Before drilling down into the technical stuff, let’s (re)define again what are HA and DRP.

What are HA and DRP (in a nutshell)

Often (mis)considered as identical, HA and DRP are two very different concepts answering to different needs.

High Availability

HA is the ability to maintain a certain service level (availability, performance) according to the defined Service Level Agreement (SLA). In other words, it is a collection of means to be used to protect a SharePoint infrastructure against the consequences of planned maintenance or unplanned outages on the SLA.

Disaster Recovery

DR is the ability to recover a whole service from a sudden, complete and persistent disaster. The term “disaster” is to be considered in a rather extended way:

  • The loss of the whole SharePoint service due to a physical loss: destruction, theft…
  • The whole SharePoint service being compromised: farm account credentials stolen, content access account credentials stolen, Windows Server’s administrators compromised…
  • A logical or physical corruption occurred in one or multiple core database, mostly in the Configuration DB
  • A SharePoint update process that does not complete successfully and leaves the farm in an unknown/unreliable state while the change cannot be rolled back

While you may sometime see some overlap, HA should never be considered as an equivalent or replacement to DRP.

The Dual Datacenter Investment

Many organizations have invested in dual datacenter architecture and this for multiple reasons: Lack os space in the first DC, lack of power, airco or whaterver or the needs for re-partition of risks or finally the need for a DC used as a safe place for recovering from a disaster. Because of this, organizations using SharePoint on-premises tend to try to map their SharePoint architecture to this dual datacenter topology by spreading servers over both sites.


Leave a comment

Office 365: MS Directory Synchronization Tool Comparison


Over time, the number of free tools provided by Microsoft for synchronizing (and sometimes syncing back) on-premises AD and Azure AD has increased up to 3 (not to mention Azure Active Directory Connector for FIM 2010 R2):

  • Directory Sync aka DirSync
  • Azure AD Sync aka AADSync
  • Azure AD Connect aka AADConnect

While the first is apparently set for retirement and the two others would ultimately merge, it is still valuable to have a good idea of their capabilities and constraints before making the right choice for each implementation.

I will later publish the upgrade paths from DirSync to AADConnect.

Tool Comparison

The table hereunder is attempt to compare them as comprehensively as possible. Please note that 95% of credit for this comparison table go to French Directory Service MVP Maxime Rastello. Here is his original French article: DirSync vs Azure AD Sync vs Azure AD Connect : lequel choisir ?

Note: I will try to keep this table as up to date as possible at the following location: Office 365: MS Directory Synchronization Tool Comparison.

Tools Directory Sync
Azure AD Sync
Azure AD Connect
Latest Version Download 1.0.7020.0000
Public Preview 2
Version History TechNet Wiki Article MSDN Article Not Currently Officially Available
Multi-Domain Sync Yes Yes Yes
Multi-Forest Sync No Yes Yes
Filtering by OU Yes Yes Yes
Filtering by Attributes Yes Yes Yes
Customizable Attribute Set Yes But Not Supported Yes Yes
Customizable Sync Rules Yes Yes Yes
Sync On-Premises to Cloud
Users Yes Yes Yes
Contacts Yes Yes Yes
Security Group Yes Yes Yes
Distribution Group Yes Yes Yes
Password Yes Yes Yes
Extended Attributes No No Yes
(Requires Azure AD Premium)
Devices No No Yes
(Requires Azure AD Premium)
Sync Cloud to On-Premises
Users No No Yes
(Requires Azure AD Premium)
Contacts No No Future Release
Security Group No No Future Release
Distribution Group No No Future Release
Password (Write-back) No Yes
(Requires Azure AD Premium)
(Requires Azure AD Premium)
Office 365 Group No No Yes
(Requires Azure AD Premium)
Devices No No Yes
(Requires Azure AD Premium)
Office 365 UPN Selection Yes But Not Supported Yes Yes
Hybrid Exchange Migration Support Yes But Single-Forest Only Yes But Single-Forest Only Yes
3rd Party LDAP Server Support No No Future Release
Assistance to ADFS Set-up No No Yes
PowerShell Cmdlets Yes Yes Yes
Staging Mode No No Yes
Hosting Server Operating System Windows Server 2008 64-bit with SP1 or later
Windows Server 2008 R2 with SP1 or later
Windows Server 2012
Windows Server 2012 R2
Windows Server 2008 64-bit with SP1 or later
Windows Server 2008 R2 with SP1 or later
Windows Server 2012
Windows Server 2012 R2
Windows Server 2008 R2 with SP1 or later
Windows Server 2012
Windows Server 2012 R2
Hosting Server .Net Framework v3.5 Service Pack 1
v4.5.1 v4.5.1
Hosting Server Domain Membership Member Server
Domain Controller
(Same Forest)
Member Server
Domain Controller
Member Server
Domain Controller
(Same Forest)
AD Functional Level Windows Server 2003 or Higher Windows Server 2003 or Higher Windows Server 2003 or Higher
Domain Controller Operating System Windows Server 2003 with SP1
Windows Server 2008 64-bit with SP1 or later
Windows Server 2008 R2 with SP1 or later
Windows Server 2012
Windows Server 2012 R2
Windows Server 2003 with SP1
Windows Server 2008 64-bit with SP1 or later
Windows Server 2008 R2 with SP1 or later
Windows Server 2012
Windows Server 2012 R2
Windows Server 2008 R2 with SP1 or later
Windows Server 2012
Windows Server 2012 R2
Note: SSO with AD FS option requires Windows Server 2012 or higher

Additional Information’s


Leave a comment

Revisiting the Microsoft Online immutable ID design decision

Originally posted on Yet another identity management blog:

Some time back I posted about Azure Active Directory synchronisation using Forefront Identity Manager (FIM) 2010 R2 and the Azure AD Connector.  My focus was multi-forest deployments, but as we know this topology was required for several advanced scenarios too.  Microsoft have since shipped Azure AD Synchronization Services (AADSync), soon to be rebranded Azure AD Connect (AAD Connect), which negates the need for FIM for most deployments and further solidifies the mentality that the Azure AD identity bridge should be separate from the enterprise identity management solution.

Having deployed quite a few FIM and AAD Connector topologies for large, enterprise customers, and having been involved in planning and design, implementation and deployment and post go live support and transfer to operations I have learned, the hard way, that the immutable ID design artefact is a massive consideration, too often overlooked and not understood.  I talked about this in my post

View original 1,074 more words


Leave a comment

Add or Modify SharePoint 2013 Search Topology using a PowerShell built User Interface

Originally posted on Karine Bosch's Blog:

In SharePoint 2013, there is no real user interface to modify the search topology. Well, there is, but you can only use for a single server farm. If you have more servers in your SharePoint farm, you have to do this through PowerShell.

One of my South-African Premier Field Engineer colleagues Scott Stewart developed a tool on top of PowerShell WITH UI to create or modify a search topology.

Read more about it here: “Add or Modify SharePoint 2013 Search Topology using a PowerShell built User Interface

A few screenshots to get you curious :)

Search topology tool

Search topology

It looks like a very promising tool! Have fun with it!

View original


Get every new post delivered to your Inbox.

Join 234 other followers