Azure AD Connect error 8244-- SOLVED

So here I was the other day setting up AAD Connect for a new employer, gotta get those account sync'd!  Anyway this being yet another in a long series of inherited networks I ran into almost every single user object in the specified OU's to be sync'd erroring out according to the Synchronization Service Manager under Connector Operations with a 'permission-issue' error 8244.

I spent some quality time with Google and found where people needed to ensure the local sync account has been added to the domain level with:

So I did that, but it did not help. I start looking into the NTFS Security permissions on the users and OU's and low and behold not a single level has inheritance enabled.

So I found this powershell blurp: https://community.spiceworks.com/topic/2120107-powershell-to-enable-inheritance

Ran this and BOOM all my objects were now enabled, however re-running a Delta sync I was still getting mass errors.  So as a test I added the sync account with FC permissions and that account's password hash was sync to AAD.  Odd I thought, so I went looking further and in the event log event 611

So using this I found, eventually, that the sync account needs permissions to edit: ms-dS-ConsistencyGuid which then led me to this:

$accountname = "<domain>\ad_forest"
$forestdn = "dc=<domain1>,dc=<domain2>"
$cmd = "dsacls '$forestdn' /I:S /G '`"$accountname`":WP;ms-ds-consistencyGuid;user'"
invoke-expression $cmd

Once I ran that, I could then see the sync account under the Security tab of all my user objects and the next Delta sync kickoff ran without any errors.

Windows 10 MPIO, Here's how to do it.

So recently I swapped my Linux Plex server with a Windows box.  Actually truth be told I re-purposed a Barracuda 410 Web Filter appliance.. It was powered by Pentium G850 which I upgraded to an I7-3770K..  Oh and before I forget to mention I did get the front NIC ports working. Ask me how :)

Anyway the point of this post is to explain MPOI in Win10. So I'm running Win 10 LTSB on this box because I don;t want some errant update screwing up my media experience. Plus my back end storage is a Drobo 810i. So I've got both Drobo nics setup for iSCSI and I wanted the front nic ports of the now dubbed 'CudaPlex' (patent pending), to be dedicated to iSCSI.

Now WIndows 10, while similar to Server 2012/2016 does not support multi-path out of the box.  But after much time spent on Google I finally found a working solution. And to help save it for posterity I'm posting it here.

Originally found on the Technet forums it worked beautifully for me.

Here's the post:

Hi

I managed to "transplant" MPIO and msdsm driver from Windows 2019 to Windows 10 Pro (1703, 1709, 1803 and 1809) with success.
The method needs to import some registry, copy necessary files into original place and manually check update for drivers.
There was slow and old Infortrend Disk Array in my test (3x Gig connected to switch with 10Gig to PC), so PC initiated 3 paths from 1x10Gig to 3x1Gig
https://i.imgur.com/tqaJq0U.png
https://i.imgur.com/k2riJi7.png
https://i.imgur.com/3Gx4OyF.png

But in fast PC + fast array (4x1Gig Array + 4x1Gig PC) it performs like this
https://i.imgur.com/B94ZumQ.png

How-to and script+files+registry are located inside zip file (link below).
https://ufile.io/u2003
Beware!!! Backup first and this "mod" is for test/educational purpose only. You do it at your own risk and take the responsibility upon yourself and you are not to blame me.

Regards
Chris

• Edited by cra3y Saturday, January 19, 2019 10:50 AM

Friday, January 18, 2019 5:42 PM

I ran a system restore backup first just to be safe but this worked perfectly for me. Both PCIe nics are dedicate to iSCSI and I gained the performance boost only attributed to MPIO after following this guys process.

Enjoy.

In case Chris's link expires here's mine: https://ufile.io/9vp34h23

Qnap 10GBe PCi card locks up device

So a few months ago I bought a Qnap TV-1635AX NAS for work to use as a backup to disk solution until my SAN arrived.

I bought this one because it has a ton of drive bays and 10GB SFP capabilities.  Word of caution: DO NOT USE QNAPS 10GBE PCI CARDS

I wanted to use copper for my 10gb, so I also bought a Qnap QXG-10G1T card.  It's supported and should be fine right?  Except not. In my case I needed to backup roughly 19TB using Veeam and Robocopy.  I started out enabling Jumbo frames to help things move along a bit faster. Within 5 hours of my job starting the unit would lockup.  For the web gui totally unresponsive, however the local LCD panel showed it was good. Tried without Jumbo frames.. same thing except maybe 10 hours into the job. Locked up tighter than tight.

I spent time with support via emails.. they were no help. I wanted to hear from an engineer on this but no such luck.

Switched to a 10GB SFP module and so far no issues. I have not summoned up the courage to re-enable Jumbo Frames but I don;t have to now since my initial jobs are complete and it's just the deltas. 

But moral of the story is, the PCI backplane in at this this model Qnap cannot support 10G over copper.

Ubiquiti Unifi Controller networks.. Corp LAN or VLAN?

So a couple weeks ago I setup my first Unifi Controller on top of Ubuntu 19.10 Server. I ended up following a script I found here and it worked beautifully!

I'll readily admit I don't always research as much as I should but I usually figure it out anyway. This time though I found something odd.  So UBNT states that unless you have a USG in your environment (or another device performing Layer 3) then you should create all of your networks in the controller as VLAN objects.

My setup here at work is not special or out of the ordinary.. I have a Sophos firewall doing the firewall duties as well as DHCP for all my subnets and routing.  When I create my wifi subnet under Networks as a VLAN DHCP traffic refuses to pass.  I don't know why, nor do I want to suffer through the inhumanity that is UBNT's chat based support one more minute.

Long story, short I spent about 5 hours one evening fighting with support over this very thing. They say 'No you need VLANS'.  I say 'Well my clients are not pulling DHCP leases from my firewall'.. they say 'You must have VLANS!'  So it was a stupid cycle.

But about maybe 15 minutes after removing that Wireless VLAN and creating a Wireless Corp LAN my clients were pulling valid leases and everything was good.

I don't know why, nor do I care at this point. Just be aware, if you run into a similar issue try a Corp LAN instead.

Ubiquiti and my configuration

So here at my new job I've been steam rolling the old network infrastructure. When I came here there was a Cisco 2602I wap, a GS series Netgear, and a Cisco SG200.  And with what I was told this place wanted to be able to do those two devices had to go.

So because I've always wanted to try them, and I think their UI is neat as hell (and the switching performance is a definite improvement over the existing) I went whole-hog into UBNT.

I have a US-8-60W, a pair of US-48's, an AC-LR, AC-Pro and 2 AC-Lites. Setting up the Unifi controller on a local virtual machine was a breeze, and adopting and configuring things was a snap.  Even migrating the controller from a Win10 guest to an Ubuntu server was overtly easy.
I NAT'd it's required ports to the outside and could access it from anywhere via the mobile app on the Cloud Access Portal.

Then I decided to take it one step further.. I need a USG for those oh so sweet ISP metrics and DPI.

So I ordered one. Now the idiot in me that does surface from time to time did not read the manual and did not checkout the help.ubnt.com articles.  I jumped right in and uplinked it to my network via it's LAN1 port.
*BIG MISTAKE*

So did I mention my idiot?  He's more of a part-time dumbass. I did not know that the USG would start plugging DHCP right out of the box and because I had snooping enabled in the controller I'm sure all sorts of backend havoc happened.

So after fighting with it myself for an hour I decided to give the Chat support a try.  Fix thing the guy asks for in a screenshot of my config under Networks. When he sees their all Corp LAN object he immediately tells me to delete them and create VLAN objects. I had a bad feeling about this but, at his behest I did it anyway.

Long story, Short I lost communication to all my servers and the controller. When I regained control I spent the next 4 hours getting my switches and APs to re-adopt and to get the wireless network to pass DHCP traffic.

In the end I had to delete the Wireless VLAN and create it as a Corp LAN object. Then.. and ONLY then did DHCP traffic begin flowing and my clients started pulling valid leases from my firewall.

So moral of the story is, not every environment will work with the best practices.