If you want to reduce the amount of time you spend at users' desks doing support and configuration, you have to...
eliminate the local operating system. That's where zero clients come in.
Virtual desktop infrastructure (VDI) can be a better way to deliver an OS to end users, but it still takes endpoints. For that, we've typically looked to thin clients, but they have their own OS, so they need a fair amount of local configuration. By removing the OS, we can reduce the surface area where potential problems can arise. VDI takes the OS from the user, and zero clients eliminate any OS on the endpoint. The result is that we don't ever have to go troubleshoot another endpoint again.
For zero-client configuration, look to the server
Zero clients are the simplest of devices. They are completely stateless devices with no fans, no hard drives, no operating system and no local configuration. In fact, in place of a typical multipurpose processor, they usually have a purpose-built chipset. Take, for example, the Wyse P25. Its "processor" is a Teradici TERA2321 PCoIP chipset. In other words, the P25 is a silent, low-power (less than 8 watts), brainless device that just sits there until it's powered on and something else tells it what to do.
You may be asking yourself if it's possible for zero-client configuration to actually be zero. The answer is both yes and no. You do have to configure the system, but not the endpoint, and there are only a couple places where your configuration will be defined.
What to configure
First and foremost, you should know that when you power on your zero client, it's going to wake up like a hungry baby bird. Baby birds can't fend for themselves. They are blind, almost deaf and too weak to stand on their own. All they know how to do is send out a beacon (chirp) in the hopes that some other entity will come over and drop food in their mouths and teach them how to be a bird.
Your zero client will do the same thing. It's going to wake up and send out a DHCP broadcast because it wants to do nothing more than connect to a broker to get its desktop. But it doesn't know what time zone it is in (let alone the time), where the broker is, what resolution it should run at or where to send its redirected media and USB streams.
Consequently, the DHCP server needs to have entries for most of those things. These are typically text entries, as opposed to A records or other pointers. Once the entries have been made, the specialized chipset in the zero client will talk to the broker and may also receive instructions from a management application. Those three things teach it "how to be a desktop."
Once you've configured your DHCP server, the next thing to do is get your zero client management application up and running. Every manufacturer has something like this. It scans the network looking for its lost little zero clients. Once it finds them, it may push out settings that you've defined in advance such as required resolution, connection server information (some models get this information here, rather than from DHCP), and restrictions on audio or USB use for compliance purposes.
Every manufacturer is different. Some units don't need a configuration server at all -- instead, everything is defined in DHCP and by the connection server -- but some will require it every time. Other zero clients may only look at the configuration server once, then store that data in a small amount of flash memory. In some rare cases, fringe manufacturers make their zero clients' first job to proactively seek out the configuration server before it can do anything else.
Ultimately, the point is that when it comes to the actual endpoint itself, there is zero configuration for you to do. Everything you do configure will be upstream of the device itself and it will only be done once. After you've built the systems around zero clients, you can take any unit and swap it or replace it with any other and it will behave exactly as the original unit did.
The best part is that because zero clients are stateless and have no moving parts, the only way they can ever really fail is if a user accidentally spills a Coke into the thing or it's otherwise physically damaged. The worst part is that we no longer have to go to user endpoints all the time, so we're likely losing the only exercise we get in a day.