Azure Active Directory Domain Services Capabilities and Limitations.

Here are the Capabilities and Limitations of "Azure Active Directory Domain Services" which you need to consider while making a decision for Active Directory in cloud.

Managed service
Azure AD Domain Services domains are managed by Microsoft. You do not have to worry about patching, updates, monitoring, backups, and ensuring availability of your domain. These management tasks are offered as a service by Microsoft Azure for your managed domains.

Secure deployments
The managed domain is securely locked down as per Microsoft’s security best practices for AD deployments. These best practices stem from the AD product team's decades of experience engineering and supporting AD deployments. For do-it-yourself deployments, you need to take specific deployment steps to lock down/secure your deployment.

Cloud Based Enterprise Directory [ Microsoft ]

Till now, we have only one way to put fully capable Active Directory in a cloud, is that we have to create an Azure VM in Azure IAAS and configure it as the domain controller. But it would require a different set of ‘cloud credentials’ to login/administer VMs in the cloud and it would be limited to the VM only. To go on next level, you can configure an AD trust relationship with your on-premises AD environment over the VPN/ExpressRoute connection. Then, you can join the virtual machines to your domain and user authentication will happen over either a VPN/ExpressRoute connection to your on-premises directory.

There are only a few benefits in doing this.
1. You extended your Active Directory to Cloud.
2. On-Premises Active Directory will replicate to Azure VM Active directory over the VPN/ExpressRoute connection.
3. You can join you Azure VMs to the domain and managed them.
4. You can use each and every functionality of Active directory in the cloud. Like, Domain Join, Group Policy, LDAP Bind/Read/Write and Kerberos/NTLM Authentication.

DFSR: Limiting the Number of Imported Replicated Folders when using DB cloning

Basic : Export a Clone of the DFS Replication Database

Before reading this article, you should read the above attached article to get the basic understanding about "DFS Replication Database Cloning". If you any questions regarding this article, please let me know. But make sure, your doubts should be clear before going further.

Cloning database can cause some problems when you have multiple Replicated Folders on a volume. Lets say, you have volume by the name of "Department" and on it you Replicated Folders like: Finance, Sales and Marketing and you are going to create one more Replicated Folder by the name "HR". Hope this small example make sense about multiple Replicated Folders on a single volume.

Here is the scenario to make you more understand with help of above example. You have three servers in your organisation, Server1, Server2, and Server3. Replicated Folders "Finance", "Sales", "Marketing" and "HR" already available on Server1 and Server2. Even on Server3, "Finance", "Sales" and "Marketing" are also there and in sync with Server1 and Server 2 but you need to add "HR" now on Server3. It means, you will first robocopy entire "HR" folder from Server1/Server2 to Server3 and then import replication database.

As per my first article about Database Cloning, i will export the replication database from Server1 as all replicated folders of the volume are in Normal state. While exporting i don't have much to do and i will end-up with the complete clone of the replication database and a configuration xml file from Server. In short, the replication database which i got after run the command, it belongs to all Replicated folders of the same volume. But i am in process to work only on "HR" folder and i don't want other Replicated Folders to be impacted.

I apologize to make it little lengthy, i just want you to make clear about the situation and scenario. Now here is the solution.

Microsoft removes 260 character limit for NTFS Path in new Windows 10

The maximum length for a path (file name and its directory route) — also known as MAX_PATH — has been defined by 260 characters. But with the latest Windows 10, Microsoft is giving users the ability to increase the limit.

Export a Clone of the DFS Replication Database

Export a Clone of the DFS Replication Database

Here i am going to explain about DFSR new feature “Database Cloning” which is introduced in Windows Server 2012 R2.

Whenever we add a new member to the replication group for the first time, replace server hardware or recover from loss of corruption of the DFS replication database. It takes long time to do the initial synchronisation which takes long time to complete and then files and folders replication starts. By this feature, we can reduce the initial synchronisation time by up to 99% under ideal circumstances.

“Source Server” from which you will export the DFS Replication Database.
“Destination Server” on which you will import the DFS Replication Database.

Changes to Keychains in macOS Sierra

This article is related to macOS Sierra 10.12.1 and 10.12.2. Because i am still working on 10.12.3 beta update to find out all keychain changes.

Recently i upgraded my macbook from El Capitan to Sierra and found that my keychain update script has stopped working. Which really made me too confused about its functionality.
My script had a function in which i mentioned the manual path of the login keychain with the $user variable which was like :

1	\Users\$user\Library\Keychains\login.keychain

But after upgrade to macOS Sierra, it has stopped working because they have change the login.keychain name.

1	\Users\$user\Library\Keychains\login.keychain-db

This change has some issues right now. Like your old script with manual path would not work and it can cause some AD account lockout issues.