This week i’ve set up the first Windows 2012 R2 domain controller at a customer. All worked good and looked fine. But when i had to create two new user accounts i found out that these two accounts weren’t replicated to the new domain controller, i’ve just set up a day erlier, nor to another domain controller in another site. I discovered also that the NTDS settings and replication topology wasn’t complete. The new domain controller had not a single connection to active directory domain services. The customer has two sites which are connected over a leased line. Both sites have their domain controllers. Those new user accounts i’ve created on an existing Windows 2008 R2 domain controller.
After nearly two days of testing and troubleshooting the problem seems to be solved. All domain controllers are replicating and talking with each other domain controllers. When i create a user account it will show up instantly on all other domain controllers. Also the replication topology is now looking good. KCC generated the missing topology now automatically, which wasn’t the case directly after the new domain controller was on duty.
I want to provide you some information about this issue and how i solved it. Probably it will help you solving your Active Directory replication issues. And if not i hope it will be at least something you can check if this patricular thing is ok and help you with troubleshooting.
Today i had again some of the problems worth writing about it afterwards. A customer called because of a strange network issue on a computer in his network. He can’t access the network drives. They are connected but he can’t access them. Also no access to UNC paths (like \\server\sharedfolder). Both ways he receives an „Access denied“ error.
So i started with some tests just to make sure we are talking the same and if at least the basics on the computer, server and network are fine. It was one of the weirdest problems i have had the last few weeks. And the solution was so simple and cheap that it is embarrassing. But i don’t want to anticipate it. Let’s have a review.
The following list describe the troubleshooting steps which we did today. I’ll hope that this „checklist“ (well, actually more a list of steps i tried) will help you if you are in the same situation as i was (or probably in a situation close to this).
checked network configuration with „ipconfig /all“
everything fine (DHCP, all expected values were correct)
checked DNS lookup
resolving server hostname, domain, different websites, all good
nslookup (reverse DNS lookup)
IP addresses are resolved to hostnames
So basically on the client it looked all good. DNS was fine, internet connection was good. But we still don’t have access to UNC paths or network drives.
the same as above (DNS / reverse DNS, generall network configuration, all was fine
checked permission for the specific user on there shares, permissions were granted correctly
DNS or permission issues are common in most IT environments. But at this time it wasn’t the root cause of this problem. Because we checked DNS and permissions and it was all fine. Let’s dig a little deeper.
Further client steps
on another computer we tried to login with the user which the customer called for
that worked all fine, no issues
on the affected computer we tried to login with another user
that worked, but the issues were the same (neither access to UNC paths nor network drives)
So now we knew that there has to be a computer related issues. Nothing with the user profile, no permission conflicts or DNS errors. But what the hell can cause this problem?
More client steps
Just to make sure there is no software causing some issues, we tried several things.
uninstall and re-installation of the antivirus program
did not help
checked other software that might could cause suche problems
we uninstalled some old pre-installed software
checked which Windows update were installed recently
we did not find any suspicious updates nor software which could cause something like that
The customer was in a hurry because he had to leave after lunch time (which we both didn’t had today). But he will call me in a few hours he said. So i ended up like a donkey at a five-barred gate. I can’t imagine were this issue has it’s root cause. All checked were good, all settings were correct. But just with this computer there is still no access to UNC paths or network drives.
A few hours later…
Later this afternoon the customer called me when he was back in the office. He said he don’t have that much time. So, let’s do this, computer. Let’s finally solve your problem.
The second last attempt was to remove this computer from the existing domain, delete the computer object in Active Directory and to join the domain again.
leaving the domain worked fine
no problems deleting the computer account
after the necessary reboots the computer wasn’t able to join the domain
„Could not join the domain. The network path was not found“
Damn, what have i done? What should i do now? Come on, it can’t be that hard! One last attempt i had in mind. What about to uninstall the network card of this computer? It can’t get any worse. Let’s try that!
uninstalled the network card via Windows device manager
also checked the box to delete driver software for this device
let Windows find a driver
surprisingly Windows found a driver (it was four years older than the previous)
network connection comes up again
restarted the computer
The customer tried to login after the last restart. Then we checked the network drives, and here they are! Access granted! A quick check with the UNC paths was also working now. Uninstalling the network card, deleting its software and letting Windows search for a driver did the trick.
The customer was happy today (the computer is for the secretariat, the user was out of office today) and the user will be happy tomorrow 🙂
Since the direct restore to Azure was announced with Veeam version 9.5 i wanted to test that and to get some hands on. But there is always either lacking of time or Murphy, which both are against me. This week I’ve been digging into this topic. I wanted to create a working configuration for a direct restore to Azure. Let me tell you this fairy tale…
I’m not completely new to cloud computing at all. I did some first steps with Amazon AWS and my first website, i tried out Microsoft Azure when it was relatively new, and i had also some tryouts with VMware vCloud Air. But all was just for testing, looking how that stuff works. No big deal at all. Now with Veeam version 9.5 this new feature called „Direct Restore to Microsoft Azure“ comes in handy.
Before you try to just configure the direct restore in Veeam Backup & Replication 9.5 there are some requirements you have to fulfill, otherwise you will do many of the setup assistants twice or more (like i had to do because i didn’t know what exactly are the requirements).
Veeam Backup & Replication 9.5
Supported in Standard, Enterprise and Enterprise Plus
Microsoft Azure Account
Pay-as-you-go or any other subscription based account
Azure Storage (blob or general storage)
Azure Virtual Network
Hint: if you organize all of this stuff above in the same ressource group on Azure you will have a better overview (at least then if you are already a heavy Azure user and if you’ve got lots of things on your Azure dashboard).
With this basics above configured we are ready to set the things up in Veeam Backup & Replication.
A really cool feature in Microsoft Active Directory is the Group Policy (or Group Policies in general). With Group Policies you can install (small) software packages, set the Internet Explorer start page, set wallpapers, execute scripts on user or computer security context and many things more. You can also deploy specific desktop icons for a user or a user group. Hence this blog post will show you how you deploy simple desktop shortcuts to a users desktop.
The group policy
If you have some specific applications in your company (for example a simple timesheet application) which your users should use, then you can create a group policy or a group policy preference respectively to deploy this desktop shortcut.
In Group Policy Management, create a new group policy object (GPO) in the „Group Policy Objects“ folder.
Right click this newly created GPO and select „Edit…“.
Navigate to „User Configuration => Preferences => Windows Settings => Desktop“
Right click the „Desktop“ object and select „New => Shortcut“
Now set all the configuration details of your application shortcut in the next dialog box.
Note: Please be aware of the „Target type“ setting. If the shortcut has to be an application shortcut, you have to choose „File System Object“. As default it’s set to „URL“ and thus creates only a shortcut for a website. Therefore if your user wants to open this shortcut, Internet Explorer (or the default browser) opens with a „cannot display this website“ message instead of the application.
On the „Common“ tab check if this group policy preference should run in logged-on user’s security context or not.
Note: If you set the „Location“ to „Desktop“ then you should make sure on the „Common“ tab the check box „run in logged-on user’s security context“ is set, because the shortcut will be published on the users own desktop. If you whish to deploy a shortcut to the „All Users“ profile then you have to set the target to „All Users Desktop“ and also uncheck the box to run this group policy preference in logged-on user’s security context. Usually a normal user doesn’t have access to all users profile, but the system account, which runs this group policy preference, has access to it.
Now click Apply / OK and close this dialog box.
As the last step, back in GPO Management, link the created GPO with the Organizational Unit in which your users reside.
Now your users have only to restart the computer or do a single log-off log-on. So they will receive the newly created desktop shortcut.
Since we know Active Directory, we know also that its replication works automatically between the domain controllers. The lowest value of this replication schedule is 15 minutes. You can’t get lower. If there aren’t that many frequent changes, or the active directory site is not large (probably with only one site) then this value should work for you.
But what if your active directory environment is larger? What if you have more than one site, on different locations, with different networks? Or what if you’ve got some remotedesktop services running in your main site and some users working with them in a branch office? What about the „i forgot my password“ cases?
Well, there is a solution for you. We can tune-up the Active Directory Inter-Site Replication. The inter-site replication works also automatically, and you can also schedule the replication only for 15 minutes. But there are some settings we can tweak to get the domain controllers pulling the changes made recently. Let me show you how to do that.
First open „Active Directory Sites and Services“ on your primary domain controller (that’s the icon with the blue „building“).
Personally i think it’s a good approach to expand first all the items in the tree, so you can make sure you don’t miss any hidden item in this tree.
Let’s start now with the tuning operation. Expand „Sites“ and „Inter-Site Transports“ (if you haven’t already). Click on the IP folder.
Now right-click (or double-click) on your site link on the right hand side. If you did not rename it it’s just the DEFAULTIPSITELINK. Then click „Properties“. Then click on the „Attribute Editor“ tab.
The attribute we should edit is called „options“. You can search for but you won’t find it. All attributes which haven’t actually a value set are hidden. To unhide it click on „Filter“ and click „Show only attributes that have values“. The checkmark disappears and now you should find the „options“ attribute in the list.
We now have to change this attribute to a specific value which allows us to tweak the inter-site replication.
You can use any combination of these. If your options attribute already has a value you need to perform a BITWISE OR operation on the existing value. If the value is 4, convert that to binary (100), perform an OR operation with binary 1, the result should be binary 101, which you convert to decimal (5) and enter as the value of the options attribute.
Now we have set this option (in my case i’ve set it to 1). That should look like that:
But there’s more. At least in my production site there wasn’t an instant replication after changing the options attribute in the inter-site link, i had to dig a little deeper.
So i searched in every site, site link and server on this active directory infrastructure for this setting and changed it to 1 everywhere. It was some clicking, but it helped.
And don’t forget these naughty bits in the NTDS settings:
Change notification will fail with manual connection objects. That is, if your connection objects are not created by the KCC (Knowledge Consistency Checker).
Conclusion for Inter-Site Replication
It was some clicking and also testing. But after changing the options attribute on every piece the result was a nearly instant replication. I created an active directory user object and it was replicated instantly to any other domain controller. Also with changes and deletion there weren’t any problems or issues. This tip with tweaking inter-site replication should help you if you don’t want to wait for 15 minutes. But think about the bandwith. Yes, bandwith. If you’ve got many changes and thus resulting some heavy active directory traffic you should keep an eye on the bandwith. This tweaking works fine for site links with 20MBit/s and more. If your branch office is connected with less bandwith (like widely used 2 or 5Mbit connections), you should probably let this setting unchanged and work with these 15 minutes instead.