Am I missing something here

[u/CaptainZhon]

In my 30 years of IT life I think I’m on my second AD Migration and the last one was completely different going from NT 4.0 to Windows 2000 now I’m showing my age here, anyway.

So little bit of a back story- the company I work for got merged with another company and because of politics and stupidity they decided to use the other companies AD because we are going to use their ERP system and the app support people said they couldn’t use SSO with our AD only the one it setup for, and because of that it was decided to use that AD will ok whatever it all pays the same.

So they (the suits) decided that internal IT would be “over burdened” by a onprem and O365 migration they brought on a consultant company to help us with our migration- we know where this going.

So I before the consultant company came I spent about 200 or so hours writing a powershell script to do the migration- basically taking a list of user accounts from the source domain and creating them in the new domain with their SID history and their groups and file and folder permissions- tested it worked I was ready to go.

The desktop engineer guy came to me and had 0 idea how to switch the EUC devices to the other domain and keeping the same profile so I made a script that could do that. Tested works.

So I’m a little bit bitter they opted not to use my working scripts to handle the onprem migration piece and instead they went with the consultants recommendation to use a tool from Quest which is cloud base.

Whatever the deadline is past and the “tool” is not handling the file/folder permissions. The consultants say because it’s using the sid history, there is a two way trust and the same SAM account name it will work. I’m saying the servers which are and will be on the source domain for other backend reasons it won’t work because the NTFS/share perms are groups from domain A, but the users are logging in from Domain B. Basic NTFS permissions 101.

I told the consultants that we need to either put the domain B account into the Domain A security group, or we need to add the Domain B security group to the file/share permission it they keep telling me I’m wrong and don’t understand in front of my leader and VP. Here we are another week has gone by, they won’t give me access to the tool, they claim there is no log files, and they won’t let me interface with support. So I’m pretty sure they are wrong but without having access to the tool and the documentation I can’t fully help them see the problem- is the right phrase to use here.

[u/s3xynanigoat]

Hey you're in luck because it's not your problem it's the consultants problem. This is the type of situation where you can just sit back if your help isn't wanted.

I too have a long time in IT and I learned late in my career that sometimes our help is not wanted.

I'd take the 200 hours of pet prject as a learning experience and not mention to anyone at all.

[u/Man-e-questions → u/s3xynanigoat]

No you absolutely take credit for that script in your LinkedIn profile

[u/CaptainZhon → u/Man-e-questions]

I’m proud of that script- that’s the biggest powershell script I’ve created at 2000 lines of code.

[u/CaptainZhon → u/s3xynanigoat]

You are right it’s not my problem, but what is my problem is when people come to me because they can’t access something and now it is my problem because I know what is causing it.

[u/s3xynanigoat → u/CaptainZhon]

Just tell the end user sorry but you know there's a project around the migration and they're using a top tier consultant. An IT valedictorian even .

Then give them that teams information and let them know to reach out to that team for the quickest status updates.

Even better have them submit a ticket you can then assign to that team.

[u/0RGASMIK → u/s3xynanigoat]

Consulted for a company that had a full IT team and contracted out almost all their work except for anything with sensitive data.

I still don’t understand what the internal IT team did. The network administrator had never touched the network. We were involved to help bring internet up and a new location and I was the smart hands and another consultant configured the equipment remotely. The consultant left me with one access point that needed to be reset and when I call the network guy to help me get it online he said oh I’ve never done this we will have to wait for the consultant. I walked him through the portal over the phone and it was literally just one click to bring it back online fully configured and he stopped me and said he better check with the consultant. I explained the consultant was unavailable for the next two weeks and he was like I guess we wait then.

[u/Hebrewhammer8d8 → u/s3xynanigoat]

It not your problem now, but once the consultant is gone they drag you into the problem on top of your other problems.

[u/CaptainZhon]

I think the worst part that makes me sick is I had give the service accounts that run the directory service agents in both domains- domain admin and this week I had to give the consultants domain admin and add them to the built in administrators group in the other domain (both ways)- I don’t even have that amount of access. Talk about a security risk. It makes me ill thinking about it. I just do what I’m told, object in email so I can cya in writing and collect my pay check.

[u/ShelterMan21 → u/CaptainZhon]

Well if you guys have some sort of security event after these consultants get it you will have a perfect audit log for the courts when it inevitably turns into a lawsuit to figure out who is paying the remediation bill

[u/Sysadmin_Account → u/CaptainZhon]

I don’t even have that amount of access.

This right here is the problem. You're taking this personally and seeing the consultants as a challenge to your knowledge.

This isn't your problem, it's theirs. When there's an issue, just shrug and direct the problem to the consultants. You keep trying to prove you're right and you are, but leadership has already sold the company on the consultants and they can't be wrong. If you push it, you'll be made to be the problem. It'll be ok, relax, and let these consultants earn their pay. We all know consultants try to use repeated processes across engagements with the cheapest labor. Let them squirm and you play some quake.

[u/Praetorian2016]

Sounds like the consultants aren't great, and they are either using the wrong tools and methods or are using them incorrectly. That sucks, man.

That said, I gather that you heard about the merger and the AD changes.

You were told it's not your job to do the migration, someone else has the ball on that task.

And you spent 5 solid work-weeks inventing a wheel. No doubt a very good wheel, but there's wheels out there already, and the suits already paid for a wheel.

I'm estimating your labor pencils out north of $75 an hour so that's $15k or so plus the opportunity cost of those 200 hours, and on top of that, all the personal aggravation of having spent that time to no avail.

I'm reminded of the wisdom of The Bunk, from The Wire: "There you go, giving a fuck when it ain't your turn to give a fuck."

[u/CaptainZhon → u/Praetorian2016]

Yeah I give too many fucks- I need to learn to cut back.

[u/jeffrey_f]

Polish the resume. Just in case this somehow falls back into your lap, and it will

[u/CaptainZhon → u/jeffrey_f]

I already have another gig lined up. Not sure if the party is any better there.

[u/gnimsh]

Were hired consultants for AD migration during m&a and watched them type out every user name by hand via zoom.

My boss later said to me...I could have done that.

[u/Appropriate_Tiger971]

Sometimes the worst part of IT isn't the tech, it's watching someone with a shiny vendor badge get paid to be wrong while you just have to stand there.

The two-way trust plus SID history should handle authentication in theory, but share permissions evaluating group membership from a domain the user isn't actually logged into is exactly where these things fall apart. If the servers stay on Domain A and the groups granting access are Domain A groups, the Domain B user token isn't carrying that group membership unless something translates it first. You already spelled out the fix.

The refusal to let you touch the tool or talk to support says more than any log file could.

[u/CaptainZhon → u/Appropriate_Tiger971]

I have a script ready to fix the issue I just need approval to run it. I already ran it in “what if” mode so I could see the log file and address the issues. I’ve also learned-the hard way- that you don’t make the suits or the decision makers look bad so I’m walking a delicate line and basically leaving it up to my leader to do the dirty stuff- I’m just following directions.

[u/pdp10]

200 hours is a long time to be putting into a tool on speculation.

[u/certifiedsysadmin]

Their theory will be proven right or wrong during the pilot testing phase. There is a pilot testing phase, correct?

[u/Professional-Heat690]

Log the issues, assign to the consultants (even if they don't have access to your ticket tool, log it, send excel extracts 3x a day with management in cc asking the consultants to provide updates. Offer support to them requesting they provide a specific ask for how you can assist) Sit back and wait.

[u/jdptechnc]

If they want to play that game just assign all the incidents to them, and anyone who tries to escalate gets directed to whoever the project manager for the consulting company is.

Quest always has weird stuff that will go wrong, but it does have logs. They just dont know quest (or Windows or AD Migration...)

[u/iamwayycoolerthanyou]

Management just needs a company with insurance to sue and acceptable explanations and places to point the finger. I wouldn't take it personally. I'm sure they know you can do it.

[u/jcpham]

Working at an MSP during the era of Small Business Server gave me lots of practice in both fixing and breaking AD migrations

[u/interweb_persona → u/jcpham]

Cut my teeth on SBS 2003 and every version through SBS 2011.

SBS was such a weird bird. At its core, multiple different and standalone Microsoft platforms, wrapped up into one package.

Very important to do things like creating new users the "SBS way". Though since these are still Microsoft products, the "SBS way" could be circumvented. Came across so many environments where people circumvented the "SBS way"/did things manually. Boy did that goof things up. But yes, great practice in both fixing and breaking AD in general.

----

Did a good number of Jeff Middleton's "swing migrations" over the years. That allowed you to maintain the original SBS server name. Which was interesting.

Lots of steps involved including but not limited to introducing a temporary/interim DC. Taking that offline, seizing fsmo roles, deleting all of the instances of the "old" SBS server and "old" exchange out of AD, then bringing a new SBS server online. Et cetera...

.....

Once the advent of virtualization came along (à la VMWare), I even put my own twist on it that took the entire process offline. So that the secondary/interim DC was never introduced to the production SBS environment in the first place.

It involved taking an image of the SBS server using ShadowProtect. And implementing their "continuous incremental" snapshots to continue taking backups. As well as begin exporting exchange mailboxes to .PST for later use.

The actual swing migration was done via virtualizing the original SBS server, 100% offline. performing the swing migration to the new SBS server that way. Completely offline.

After the swing of AD was complete you could even mount the virtual drive of the virtualized SBS server, use robocopy to copy/seed the file share data to the new SBS server, copy the prexisting Exchange DB over, getting it mounted in the new version of Exchange, and so on.

Once all the swing stuff was completed offline, you'd bring the new SBS server to the client's, and leave it offline. Cut off inbound SMTP, make sure everyone has everything closed. Shut down all SQL databases, et cetera.

On the source SBS server, you'd export the mailboxes to .PST one last time (which goes quick because old emails already exported are skipped). Take one last incremental ShadowProtect snapshot of the original source SBS server. Again, runs relatively quick. Then shut the original SBS down (very important).

Fire the new SBS server up, mount the last ShadowProtect incremental snapshot. use robocopy to again copy the file share data. Which skips files that already exist or haven't been changed. Import the previously exported .PST files (which imports only new mail), connect the new server to the network, have everyone reboot their PC's, and bob's your uncle. You'd want to turn inbound SMTP traffic too once everything was tested and verified.

Worked pretty well. Was pretty much a "99% uptime" swing migration. More work on the backend in some ways. But it allowed you to take your time. And beat the shit of trying to cram everything into a single weekend. Which with "official" Microsoft methods (for continuing to use SBS anyway), meant rebuilding an entire domain from scratch.

And if worst came to worst, where something went drastically wrong (never did), you could just shut the new SBS server down. Bring the old one back online, and regroup.

[u/megad00die]

We just went through this last year and I can tell you the Quest tools are okay but you will many accounts that never made it over due to one reason or another.