A few things I really, really need W8 to support... RRS feed

  • General discussion

  • So, there are a few things that would make my life as a system adminsitrator much more "friendly", so I thought I'd post them here in the hope that someone could either give me some advice for work-arounds, or that someone from the W8 team will see it and consider it;

    1. Printer management and deployment.
      Why, oh why, did Microsoft create a "printer Management" process that has settings for deploying printers to "users" or "computers", and then write it such that the "computers" deployment method is triggered on "user" logons, and are per-user? In a multi-user environment where we need to target specific "labs" with the printer that is in that room... the current method sucks. It, for some unknown reason, can take over five minutes PER-LOGON to get the printer to show up. Even if the required driver (HP Universal in our case) is already installed and working on the computer.

      To resolve this for the time being, we have actually removed all of our "Deployed Printer" settings and have actually packaged up the printer/port registry information ourselves, and converted it to HKLM (from HKCU). We then deploy this by stopping the Spooler, injecting the registry, and starting the spooler. This method works perfectly, is truly per-machine, and is super fast. It doesn't make sense that, even the built-in "Printer Management" VBScripts provided in Windows can't make per-computer installs. It even has a "per-machine" switch for the command-line, but doesn't actually work.
    2. User session tracking and reporting.
      One thing i truly love about the Macs we have on site, is that system can record user session statistics, including: Who was logged on, and at what time; How long their session was (and when they logged out); What applications were used during that time; And of the application used, how much time each spent in the foreground; It also tracks idle time, sleep time, etc, during the session. And all of this information can be either pulled directly from the client, or handled automatically via the "Apple Remote Desktop" application and a "Task Server".

      Currently there are a lot of small utilities that can do some magic in exporting some (but not all) of this information - and cost a fair amount of money. There are others that want to load various client and agents onto the system (potential security and stability risk) for the sole purpose of "Application Metering". It would be immensely helpful if we could have an official way to pull important stats like this from our systems. Built-in licensing and application metering (and user session logging) would be invaluable to our business. How can Apple do this so easily, and yet there is no nice way to do it on Windows. Frustrating.

      Another "great" feature, is that the whole user session is controlled via the "LoginWindow" on an Apple. This is like the "WinLogon" only more persistent. You can hook into this for "login scripts" and "logout scripts", and that makes certain admin tasks a breeze. Windows seems quite capable of performing "startup" operations and "login" scripts... but is woeful at "logout scripts" and "shutdown scripts". Even if you use the GPO methods for these, they do not function like they should. Failing the ability to pull user session information and application metering from the system as a built-in function, I would like to code my own... but have no nice framework on which I can attach this other than a GPO logoff script... which I don't trust.
    3. Utility feature parity between servers and clients.
      On of my recent pet hates is the fact that "Windows 7" and "Windows Server 2008 R2" may have the EXACT SAME utility (name), in the same location, for doing a specific task, and yet the client version has been crippled... why? Here's an example: VSSADMIN. This utility, when run on a server, let's you list, create and delete providers, writers, etc. You can easily, as a system admin, configure a server to enable Volume Shadow Copy on certain volumes, and set their storage limits, etc. On "Windows 7", even the "Professional" or "Enterprise" versions, you can only use the utility to lsit and delete VSS information. You cannot create. So what should have been a simple script during the imaging of mass computers, turned into a manual GUI configuration operation before hand-over... which MASSIVELY blew out or deployment time-frame.
    4. Stop providing GUI-only access to features.
      Another annoyance of mine, is the seemingly intentional and frustrating way Microsoft provides certain features to Windows Client OS users. In a domain environment, I would like to set (via GPO) the Windows Update settings and use WSUS. If, however, you choose any option other than the Microsoft "Recommended" setting of "Download and install [and reboot]", then you end up with a warning in the Action Center of every user of the computer. These "Action Center" and "Security Center" options cannot be captured. If you set it for one user, then capture the profile as a "default" using "CopyProfile" (or other methods) and ALSO capture the image... then try to deploy that, the setting is back. It appears to encode the user/computer information into the "Action Center" binary information. This means that I need a manual "click hide on the Windows Update" process before hand-over as well. Why can't we control this via a scripted or default user profile approach?

      Other examples are the "indexing Options" and "Volume Shadow Copy" options, etc. While the "indexing Options" can be set via a "Default index" in Group Policy, it would be nice to not have to rely on that to enable indexing on a second partition of the disk image. This should be a setting that can be captured during the image build process. I understand that the process uses volume IDs in teh registry, and those change between computers... but surely there is an answer. The second program was covered in my previous point... in that a program exists that has the same name as the one that will work... but is missing the critical functionality to make it actually work. You need to perform this operation int e GUI.
    5. Can we please move the performance checks.
      Moving the "checking performance" process to just before the login-Window, instead of the first action in the OOBE, would be a huge help. I know that I'm meant to inject drivers into the system at capture, or use DISM and SYSPREP, but that process has potential to really bloat out our images and cause issues with driver updates. Our process simply uses the post-OOBE "SetupComplete.cmd" process to install an array of drivers that are pulled from the network at deployment. This allows us to update a single driver on the network, redeploy the image, and BAM... updated. Unfortunately, this causes all manner of issues with the availability of a graphics driver. The performance tests often see our computers as having VGA cards and disable Aero. I've taken to adding a RunOnce registry key that performs a WinSAT update to make this all work. It would be nice if we can ensure the entire setup process is complete before having these tests performed. That way deployment methods like ours (and we're not the only ones using this method) will work without further post-image meddling to enable a visual style. Obviously Intel have started coding in a WinSAT update into their driver installs to avoid these very issues... but we shouldn't need to.
    6. I have a lot more... but the post is already huge. I will add more later :)
    Thursday, February 23, 2012 5:37 AM