Latest Entries »

Microsoft’s file systems organize storage devices based on cluster size. Also known as the allocation unit size, cluster size represents the smallest amount of disk space that can be allocated to hold a file. Because ReFS and NTFS don’t reference files at a byte granularity, the cluster size is the smallest unit of size that each file system can reference when accessing storage. Both ReFS and NTFS support multiple cluster sizes, as different sized clusters can offer different performance benefits, depending on the deployment.

Full article from MS:


ReFS cluster sizes

ReFS offers both 4K and 64K clusters. 4K is the default cluster size for ReFS, and we recommend using 4K cluster sizes for most ReFS deployments because it helps reduce costly IO amplification:

  • In general, if the cluster size exceeds the size of the IO, certain workflows can trigger unintended IOs to occur. Consider the following scenarios where a ReFS volume is formatted with 64K clusters:
    • Consider a tiered volume. If a 4K write is made to a range currently in the capacity tier, ReFS must read the entire cluster from the capacity tier into the performance tier before making the write. Because the cluster size is the smallest granularity that the file system can use, ReFS must read the entire cluster, which includes an unmodified 60K region, to be able to complete the 4K write.
    • If a cluster is shared by multiple regions after a block cloning operation occurs, ReFS must copy the entire cluster to maintain isolation between the two regions. So if a 4K write is made to this shared cluster, ReFS must copy the unmodified 60K cluster before making the write.
    • Consider a deployment that enables integrity streams. A sub-cluster granularity write will cause the entire cluster to be re-allocated and re-written, and the new checksum must be computed. This represents additional IO that ReFS must perform before completing the new write, which introduces a larger latency factor to the IO operation.
  • By choosing 4K clusters instead of 64K clusters, one can reduce the number of IOs that occur that are smaller than the cluster size, preventing costly IO amplifications from occurring as frequently.

Additionally, 4K cluster sizes offer greater compatibility with Hyper-V IO granularity, so we strongly recommend using 4K cluster sizes with Hyper-V on ReFS.  64K clusters are applicable when working with large, sequential IO, but otherwise, 4K should be the default cluster size.

NTFS cluster sizes

NTFS offers cluster sizes from 512 to 64K, but in general, we recommend a 4K cluster size on NTFS, as 4K clusters help minimize wasted space when storing small files. We also strongly discourage the usage of cluster sizes smaller than 4K. There are two cases, however, where 64K clusters could be appropriate:

  • 4K clusters limit the maximum volume and file size to be 16TB
    • 64K cluster sizes can offer increased volume and file capacity, which is relevant if you’re are hosting a large deployment on your NTFS volume, such as hosting VHDs or a SQL deployment.
  • NTFS has a fragmentation limit, and larger cluster sizes can help reduce the likelihood of reaching this limit
    • Because NTFS is backward compatible, it must use internal structures that weren’t optimized for modern storage demands. Thus, the metadata in NTFS prevents any file from having more than ~1.5 million extents.
      • One can, however, use the “format /L” option to increase the fragmentation limit to ~6 million. Read more here.
    • 64K cluster deployments are less susceptible to this fragmentation limit, so 64K clusters are a better option if the NTFS fragmentation limit is an issue. (Data deduplication, sparse files, and SQL deployments can cause a high degree of fragmentation.)
      • Unfortunately, NTFS compression only works with 4K clusters, so using 64K clusters isn’t suitable when using NTFS compression. Consider increasing the fragmentation limit instead, as described in the previous bullets.

While a 4K cluster size is the default setting for NTFS, there are many scenarios where 64K cluster sizes make sense, such as: Hyper-V, SQL, deduplication, or when most of the files on a volume are large.

Web article:


How to test SSL/TLS:

You can easily see what SSL protocol a server supports (and even grab the certificate from there) example below with openSSL:

openssl s_client -connect myserver.mydomain.local:636 -ssl3
openssl s_client -connect myserver.mydomain.local:636 -tls1
openssl s_client -connect myserver.mydomain.local:636 -tls1_1
openssl s_client -connect myserver.mydomain.local:636 -tls1_2

All those reports successfull connection SSL handshake and present the proper server certificate.

And it is very easy anyway for a client to get supported SSL protocols on a remote server, it is how client <==> server handshake works to
select an agreed protocol supported on both sides.

I suggest you check on application side …

# nmap –script ssl-enum-ciphers -p 636 myserver.mydomain.local

Starting Nmap 6.46 ( ) at 2017-02-16 18:22 CET
Nmap scan report for myserver.mydomain.local (
Host is up (0.025s latency).
636/tcp open ldapssl
| ssl-enum-ciphers:
| SSLv3:
| ciphers:
| TLS_RSA_WITH_RC4_128_MD5 – strong
| TLS_RSA_WITH_RC4_128_SHA – strong
| compressors:
| TLSv1.0:
| ciphers:
| TLS_RSA_WITH_AES_128_CBC_SHA – strong


Reference article:

Kerberos uses SPNs extensively. When a Kerberos client uses its TGT to request a service ticket for a specific service, the service is actually identified by its SPN.  The KDC will grant the client a service ticket that is encrypted in part with a shared secret that the service account as identified by the AD account that matches the SPN has (basically the account password).

In the case of a duplicate SPN, what can happen is that the KDC will generate a service ticket that may be created based on the shared secret of the wrong account.  Then, when the client provides that ticket to the service during authentication, the service itself cannot decrypt it and the auth  fails.  The server will typically log an “AP Modified” error and the client will see a “wrong principal” error code.

So, duplicate SPNs are very bad, much in the same way that duplicate UPNs are bad.  Both can cause Kerb auth to break and Windows uses Kerb for auth everywhere it can.


To identify duplicated accounts:

you can use the command: setspn -q <service/server:port> ; to find SPN duplicate on the forest
orusing setspn -L <computername> ; to list the SPN associated to a computer AD object

or by looking Event ID 11, source KDC on Domain controllers event log

How to move Office 365 data to another Office 365 tenant?

this will includes:

  • exchange online mailboxes
  • sharepoint online data
  • onedrive online data

Read those articles:

Microsoft does not provide at the moment the possibility of transferring mailboxes, Sharepoint and OneDrive data in an automated manner between Office365 tenants

It is not possible to connect between the Office365 servers and send data from one to another. However, with the help of third-party tools like MigrationWiz from BitTitan, Quest Migration Manager from Dell, Sharegate-created especially for the Sharepoint and others – you can prepare and go through the migration process.

Third-party tools can only copy the data, not syncing them!

You need to prepare customers that using third party tools to migrate Office365 between tenants, contents of mailboxes and Sharepoint/One Drive data are copied from one location to another. For example, if mail message has been copied to the destination mailbox and will be removed in source mailbox, then it will still exists in the destination.

• OneDrive for Business (or OD4B)

In the Office365’s OneDrive each user gets their own, separate data space on Sharepoint Online server. At the time of writing this article it is 1 TB. Administrators problem is that by default, this is designed as a user private storage, so until changes of permissions they cannot access it and so migrate data. To copy it across the Office365 tenants, administrator permissions needs to be added to OneDrive sites. You can achieve this via Powershell script for all OneDrive sites.:

$Creds = Get-Credential
Connect-SPOService -Url -credential $Creds
$Users = Get-SPOUser -Site -limit all| Where-Object {$_.LoginName -like ‘*DOMAINNAME.DOMAIN*’}
$Users = $Users.LoginName | ForEach-Object { $_.TrimEnd(“DOMAINNAME.DOMAIN”) } | ForEach-Object { $_.TrimEnd(“@”) }
$Users | ForEach-Object {Set-SPOUser -Site”$_”_DOMAINNAME_DOMAIN/ -LoginName -IsSiteCollectionAdmin $true}

or only for selected OneDrive’s if you prepare list beforehand (here it is named O4bUsers.csv)

$Creds = Get-Credential
Connect-SPOService -Url -credential $Creds
$Users = import-csv ./O4bUsers.csv
$Users | ForEach-Object { Set-SPOUser -Site $_.url -LoginName -IsSiteCollectionAdmin $true }

The second issue related to OneDrive migration, is the fact that when you move its data to a new tenant, you need to prepopulate O4B sites first-they are not automatically created when you assign license to Office365 user.

Here comes Powershell again, however it is required to use complex script and prepare a list of accounts to be created beforehand.

You can get relevant information here:

During preparation of migration batches, be careful entering account parameters.

OneDrive and Sharepoint links will change accordingly to the domain connected to user UPN – that is when UPN (login name) changes, OneDrive url will change too – for example:

can change to:

Due to this process, you must set the correct source and destination addresses in the migration tools. Be aware and do not migrate data in the wrong way!

• SharePoint world

Although it is integrated with other Office365 services, it is a separate environment, which is governed by its own laws. It can have its own set of users, permissions, and services you need to keep in mind during the migration.

Microsoft has no out of the box solution to transfer data, configuration and structure between Office365 tenants, however, there are third-party tools which can help you with the migration.

The complexity of all of the Sharepoint features causing that there is no application that can mirror everyone environment in the new place. Every tool on the market has always some limitations. You need to check the documentation for a list of functions and properties that can be included in the migration and exceptions that just cannot be migrated.

Even though you choose the best tool, it is useful to have Sharepoint specialist on board on the planning phase, during and just after migration to help solving emerging problems.

• Switching domain-downtime in the mail delivery

To move organization data from one Office365 tenancy to the other, one of the steps you need to perform is a domain migration. You cannot assign the same domain to two Office 365 tenants. You need to remove it from the existing one first, then add and verify in the second. This will be possible if you remove any domain aliases assigned to Office365 objects -mailboxes, groups, contact. This step is critical, because removing domain will stop mail flow directed to it.

If we do not use additional servers, which can take over the mail traffic for the duration of the switching domains (switching consists of removing, adding and verifying domain, changing MX records, waiting for DNS replication), for example hybrid on-premises Exchange Server, or Linux server – there will be a downtime in the mail service for selected domain.

You have to get this into account during planning stage and preparing migration steps for customer.

It is even more important when there are many, sometimes several hundred SMTP (mail) domains to migrate between the Office365 tenants, and at the same time you can get the verification code only up to 50 domains.

It is possible that you can also encounter unplanned obstacles, for example in the form of damaged objects – in my case it was when I cannot remove aliases and needed to remove object completely.

Some migration solutions:

for sharepoint:

read the article:

for onedrive:

All in one suite:



Office 365 objects:

How to recognize objects created directly in the Office 365? You can check date of their synchronization with the AD. Cloud users, groups and contacts which have never been synchronized with the directory service, will have the lastdirsynctime parameter set to null ($null).

Powershell commands to check cloud identities:

get-msoluser-all | where {$ _. lastdirsynctime-eq $null}

get-msolgroup-all | where {$ _. lastdirsynctime-eq $null}

get-msolcontact-all | where {$ _. lastdirsynctime-eq $null}


The administrator receives email notifications that identify which certificates are set to expire on the specified day.


SSL certificate checker:


third-party:   ; true-Xtender certificate expiration service


On Office 365 landing page:

How to Disable OneDrive for Business in Office 365

On Office 2016 package – by GPO:


Aucune entrée Apple Mobile Device USB Driver affichée

  1. Déconnectez votre appareil de l’ordinateur.
  2. Effectuez une capture d’écran en appuyant simultanément sur le bouton principal et sur le bouton Marche/Veille (l’écran doit alors clignoter brièvement).
  3. Reconnectez l’appareil à votre ordinateur.
  4. Si l’une des sections suivantes s’affiche dans le Gestionnaire de périphériques (device manager en Anglais), agrandissez-les :
    • Périphériques d’images
    • Autres périphériques
    • Appareils mobiles
    • Contrôleurs de bus USB

Recherchez à présent l’entrée qui reconnaît l’appareil en tant qu’appareil photo. Vous devriez voir s’afficher « Apple iPhone », « Apple iPad » ou « Apple iPod ». Cliquez avec le bouton droit de la souris sur l’entrée de l’appareil, puis mettez manuellement à jour le pilote Apple Mobile Device USB Driver.

Si seule l’entrée Périphérique inconnu s’affiche :

  1. Cliquez avec le bouton droit de la souris sur l’entrée Périphérique inconnu.
  2. Choisissez Propriétés dans le menu contextuel et cliquez sur l’onglet Détails.
  3. Dans le menu déroulant, sélectionnez Numéros d’identification du matériel.
  4. Si l’identifiant ne commence pas par USB\VID_0000&PID_0000, rendez-vous dans le Gestionnaire de périphériques et faites un clic droit sur l’entrée Périphérique inconnu, puis mettez manuellement à jour Apple Mobile Device USB Driver.
  5. Si l’identifiant commence par USB\VID_0000&PID_0000, suivez les instructions ci-dessous.
  6. Déconnectez l’appareil et débranchez tous les périphériques USB de l’ordinateur.
  7. Éteignez, puis rallumez l’ordinateur.
  8. Reconnectez l’appareil et testez chaque port USB pendant environ 30 secondes pour vérifier si l’appareil est reconnu.
  9. Effectuez un test avec un autre câble Apple 30 broches vers USB ou un autre câble Lightning vers USB fiable, le cas échéant.

Si le problème persiste, contactez l’assistance Apple.

Mise à jour manuelle du pilote Apple Mobile Device USB Driver

Si l’une des sections ci-dessus vous redirige vers cette section, il se peut que vous ayez déjà effectué un clic droit sur une entrée du Gestionnaire de périphériques. Effectuez à présent la procédure suivante :

  1. Choisissez Mettre à jour le pilote logiciel.
  2. Sélectionnez « Rechercher un logiciel pilote sur mon ordinateur ».
  3. Sélectionnez « Me laisser choisir parmi une liste de pilotes de périphériques sur mon ordinateur ».
  4. Cliquez sur le bouton Disque fourni. Si cette option ne s’affiche pas, choisissez une catégorie d’appareil, telle que Téléphone mobile ou Périphérique de stockage, si disponible dans la liste.
  5. Cliquez sur Suivant. Le bouton Disque fourni devrait s’afficher.
  6. Effectuez une recherche dans C:\Program Files(x86)\Common Files\Apple\Mobile Device Support\Drivers (si vous avez un PC sous Windows 32bit) ou C:\Program Files\Common Files\Apple\Mobile Device Support\Drivers  si vous avez un Windows 10 64bit .
  7. Double-cliquez sur le fichier usbaapl. Si vous utilisez une version 64 bits de Windows, ce fichier porte le nom de « usbaapl64 ». Si le fichier « usbaapl64 » ne s’y trouve pas ou s’il n’existe aucun dossier Drivers,
  8. Dans la fenêtre Disque fourni, cliquez sur Ouvrir, sur Suivant, puis sur Terminer.
  9. Windows installe alors le pilote. Si un message s’affiche, indiquant que le logiciel que vous installez n’a pas été validé lors du test permettant d’obtenir le logo Windows, cliquez sur Continuer quand même. Vous pouvez obtenir de l’aide concernant les autres erreurs et numéros de code d’erreur courants dans cet article Microsoft.
  10. Ouvrez iTunes afin de vous assurer qu’il reconnaît bien votre appareil. Si ce n’est pas le cas, redémarrez le service Apple Mobile Device.

Main resources:



Two ways to integrate/federate applications with Azure AD:

Azure marketplace:

check if the application exists:

The Microsoft Azure Marketplace is an online store that offers applications and services either built on or designed to integrate with Microsoft’s Azure public cloud.

Else, how to configure single sign-on to applications that are not in the Azure Active Directory application gallery:

Authentication scenarios for Azure AD:

Applications integrated with Azure: the access via

Integrating applications with Azure AD:


Identity hybrid ports and protocols:


Azure app gallery:

If not pre-packaged in Azure marketplace: Any app that supports SAML 2.0 can be integrated directly with an Azure AD tenant using these instructions to add a custom application.

Provide credentials for a test tenant or account with your application that can be used by the Azure AD team to test the integration.

Provide the SAML Sign-On URL, Issuer URL (entity ID), and Reply URL (assertion consumer service) values for your application, as described here. If you typically provide these values as part of a SAML metadata file, then please send that as well.

Provide a brief description of how to configure Azure AD as an identity provider in your application using SAML 2.0. If your application supports configuring Azure AD as an identity provider through a self-service administrative portal, then please ensure the credentials provided above include the ability to set this up.

Configuring single sign-on to applications that are not in the Azure Active Directory application gallery:


Sign On URL (SP-initiated only) – Where the user goes to sign-in to this application. If the application is configured to perform service provider-initiated single sign on, then when a user navigates to this URL, the service provider will do the necessary redirection to Azure AD to authenticate and log on the user in. If this field is populated, then Azure AD will use this URL to launch the application from Office 365 and the Azure AD Access Panel. If this field is ommited, then Azure AD will instead perform identity provider -initiated sign on when the app is launched from Office 365, the Azure AD Access Panel, or from the Azure AD single sign-on URL (copiable from the Dashboard tab).

Issuer URL – The issuer URL should uniquely identify the application for which single sign on is being configured. This is the value that Azure AD sends back to application as the Audience parameter of the SAML token, and the application is expected to validate it. This value also appears as the Entity ID in any SAML metadata provided by the application. Check the application’s SAML documentation for details on what it’s Entity ID or Audience value is. Below is an example of how the Audience URL appears in the SAML token returned to the application

Reply URL – The reply URL is where the application expects to receive the SAML token. This is also referred to as the Assertion Consumer Service (ACS) URL.