Fun with Group Policy

HCHTech

Well-Known Member
Reaction score
4,138
Location
Pittsburgh, PA - USA
We did a server migration for a client recently, and because we wanted to maintain the same drive letters for the mapped drives from the old server to the new, I used the "Replace" option in my mapped drive group policy. So far, so good, right? It worked l like a charm, everyone got the change and all of the 6 different mapped drives kept their same letters but now pointed to the new server instead of the old.

What I should have done, though, was edit this policy so that the mapping was set to "Update" after the migration was finished. Because I missed this step, we chased a problem for over a week with one of their LOB softwares kicking out users if they left the software up for an extended period of time. What was happening was that the "replace" policy was running (the schedule is different for every user since they don't all log into their computers at the same time.) When the policy ran, it momentarily disconnected the drives, then reconnected them, which made the LOB software think the network went down, so it crashed and the user was unceremoniously kicked out of the application, losing any unsaved data.

It took us a while to figure out the problem, and as usual, about 30 seconds to fix it once we figured it out. A nice "hoisted by my own petard" problem to solve on a Friday. Ugh.
 
What you should have done, is deployed DFS, changed the maps to utilize the DFS names, so in the future you can move to a new file server without touching the policy at all!

But yes, replace does exactly what it says and will force disconnects. Maddening to troubleshoot for the first time!

And note, you NEEDED it to be replace for the cut over, update isn't aggressive enough to get all the maps to move.
 
Last edited:
What you should have done, is deployed DFS

To be honest, I haven't really shaken down DFS yet, but besides that this was an accountant office who used CCH ProSystems, which doesn't outright forbid DFS, but they do have a list of the errors you are likely to encounter in day-to-day use if you have it, and basically say "don't call us". That, and the horrible timing of this replacement (right at the start of tax season), meant I needed have the absolute minimum of downtime possible, so we did a like-to-like setup. If I had to do it over again more seriously looking at DFS, I think I would have made the same choice.
 
To be honest, I haven't really shaken down DFS yet, but besides that this was an accountant office who used CCH ProSystems, which doesn't outright forbid DFS, but they do have a list of the errors you are likely to encounter in day-to-day use if you have it, and basically say "don't call us". That, and the horrible timing of this replacement (right at the start of tax season), meant I needed have the absolute minimum of downtime possible, so we did a like-to-like setup. If I had to do it over again more seriously looking at DFS, I think I would have made the same choice.
You really should look at DFS. If AD is involved, it makes this work brain dead easy.

No, I'm not talking about replication... just the REDIRECTION.

It lets you publish shares right off the AD name, and then direct them as required.

So instead of \\server\share, your scripts use \\domain.tld\dfsroot\share

And now you can redirect that stuff at a click. When I find my engineers deploying file servers without using DFS I actually get physical at this point, we're making more work for ourselves in the future to bill for when we don't do our diligence, it's unethical.

But then again, I'm not deploying File Servers anymore. One dies, data goes into SharePoint.
 
Last edited:
I see also that you can do a mapped drive pointing to a DFS share, which might satisfy old software whose developers stopped learning new things in 1995. In that case, it would have the same benefit - the map would point wherever the share was on the network.
 
I see also that you can do a mapped drive pointing to a DFS share, which might satisfy old software whose developers stopped learning new things in 1995. In that case, it would have the same benefit - the map would point wherever the share was on the network.
Exactly! And if you need to relocate that share, you just schedule it, copy it, add the new target to DFS, and activate.

No scripts to update.
No GPOs to mangle.

It just swaps.

The first time you do it, I promise you'll be wondering why you've ever done share migrations via any other method.

The only rub is, you do need AD, and the endpoints must be joined to AD. Then there's the huge nail in the coffin of the very concept of a file server being a dead one if you want a properly secure environment.

But there is so much legacy crap out there... and you do what you have to.

Also, you won't convert to using DFS unless you're migrating the file server because you have to go edit everything to use the DFS target. Which is why you have to keep it in your mind when you need to move shares around, you're going to edit all of that to move to the new server anyway, best to do it such that you won't have to do it again. But from a cost perspective, clients aren't going to pay you to move stuff twice.
 
Last edited:
But from a cost perspective, clients aren't going to pay you to move stuff twice.

Well, as a T&M shop, my clients do pay for my time, whether I'm doing things the most efficient way or not. I doubt in a 12 person office like this was, the additional time required to do things the old way is really not an issue until the NEXT server migration, likely 5 or 6 years away unless they grow a lot. The time of THIS migration would likely have been the same because of the setup time of DFS in the first place before the migration. This is just one of those tricks you learn along the way that makes your future life easier. I will absolutely be looking at setting this up for my 45-employee client, though They got new servers in 12/21, so DFS would darn sure make that future migration job easier = makes sense to spend the time now to set it all up.
 
@HCHTech You have it nailed sir!

You have to figure out when that investment makes sense, sometimes that means using DFS gradually to improve the environment over time, sometimes that means when you do the file server setup, and run around like mad editing configuration files, drive mappings, and any scripts you can find.

But beware the T&M thing, we do the same for projects and it bugs me that a "good engineer" bills less. Why should we make less money because we're better at our jobs? T&M will eventually sink you, BUT again we still use it too. But I also have fixed fee project paperwork for projects where we're certain of the outcome. Don't sell yourself short! Sell your VALUE NOT YOUR TIME!

This nibblet brought to you by our glorious Technibble founders. :D
 
...That "good engineer" should have a higher billable rate than those floating down at the average level. I have thought about this multiple times for my business, but it only makes sense, IMO when you have a staff large enough to silo the projects (which also means you are typically dealing with larger clients who are used to this kind of thing). We have 3 techs and they all do everything, so I just can't see pushing for different billable rates.
 
We have 3 techs and they all do everything, so I just can't see pushing for different billable rates.

And I have one, me, and it's the same for anything in the "general purpose computing" arena. I will go to my grave being a T&M biller because that's the only thing I consider to be fair. It's what I expect to pay when I engage service providers. "Flat rate" always "favors the house" not the customer, and "the house" generally doesn't need to be favored to begin with.

I do have a significantly higher hourly rate if a private individual has hired me for assistive technology work, because there are so few out there who have any background and know how to set things up right. The state agency that has me do this kind of work has a rate slightly lower than my usual "general purpose computing" rate just due to the amount of work they throw my way and, of course, they set the rates. You take what they pay or you don't take the work - your choice.
 
a T&M biller because that's the only thing I consider to be fair.

Yes, I'm with you there. We have one residential rate and one commercial rate that we adjust at least every other year. We did an increase in both 1/1/24 and 1/1/25 because we just had to. The cost of everything we buy as a business went up significantly. It's frustrating, but I didn't get any pushback.
 
...That "good engineer" should have a higher billable rate than those floating down at the average level. I have thought about this multiple times for my business, but it only makes sense, IMO when you have a staff large enough to silo the projects (which also means you are typically dealing with larger clients who are used to this kind of thing). We have 3 techs and they all do everything, so I just can't see pushing for different billable rates.
We have a rate card, and it's billed based on the kind of engineer.

Service Desk
Field Services
Project Manager
Consulting Engineer
Cloud Engineer
Security Engineer

That's not quite what we use, but as a breakdown is close enough for the conversation.

The problem with this structure is that in terms of project delivery the client doesn't care. The sales process is based on value of the project, which has little to do with the engineers and other staff that worked on it. We need to quickly bid on jobs to get work, but at the same time we need to have an idea of the cost of the people used to deliver it to ensure Sales is selling correctly, and armed with the knowledge they need to project the value of the service being offered.

That's not T&M anymore, it's T&M plus some estimate of the cost of NOT doing the project.

I don't have a perfect answer here, I just know that raw T&M leaves money on the table and doesn't allow you to retain talent or scale. It's that former bit I've see kill small jobs. Key individuals realize they can get a huge raise and abandon ship. Then as the owner of the small shop you're left scrambling. In your case, it's less of an issue because you're an engineer too, you just start putting in more hours. But that means you're working for the business instead of on the business, which causes a slew of other problems.

I know... welcome to SMB. This really can't be fixed, I'm just complaining out loud.
 
I know... welcome to SMB. This really can't be fixed, I'm just complaining out loud.

So it boils down to picking the poison that you, the business owner, find the least toxic.

I have yet to find most of us at the micro end of this business not choosing to keep T&M billing for a multitude of reasons. But as you scale up things change. Many of us never will "scale up" because we're not seeking to "scale up." One of the things I love about my semi-retirement side gig is that it's me, and only me, that I answer to. That's worth it's weight in gold even during those times when I'm not raking in same (which is most times, as I get older). What I might have needed or wanted in my 20s, 30s, and 40s, is not what I want in my 60s.
 
Many of us never will "scale up" because we're not seeking to "scale up." One of the things I love about my semi-retirement side gig is that it's me, and only me, that I answer to. That's worth it's weight in gold even during those times when I'm not raking in same (which is most times, as I get older). What I might have needed or wanted in my 20s, 30s, and 40s, is not what I want in my 60s.
Exactly this. It was never about chasing more - more money, more status, more things.
Boats, cars, luxury holidays in the Bahamas... none of that ever held any real value for me.
What mattered was the satisfaction of doing something well, on my own terms. That sense of accomplishment? Priceless.
No flashy purchase can compete with that.
 
Back
Top