TG_MI

If the root cause of your problem is that Windows displays the last logged on user, you can disable that via group policy. Computer Configuration-->Policies-->Windows Settings-->Security Settings-->Local Policies/Security Options-->Interactive Logon-->Interactive logon: Do not display last user name (Set to enabled). Doing so forces the next person to enter a username and password. You can set an account to autologon, but that seems messy to me, especially considering that it requires entering a username and password into the registry...

Just as a troubleshooting step, I'd toss a test system into an OU in AD that has minimal/no GPO's applied to it to rule out group policy processing as a possible cause. Be sure to run a gpupdate /force /boot before doing a test login with a "new" user to make sure the system is rebooting with little to no group policy processing. I do know that Windows 8 handles certain aspects of group policy processing differently, though I thought it was optimized to speed up login, not slow it down. IIRC, I think it does things like delay the execution of logon scripts until after logon etc. This may be helpful if you think that's the direction of your issues: What's New in Group Policy in Windows Server

That may very well be Psy. Maybe I'm doing it the hard way. I've always just grabbed it by: Navigate to .exe in question --> Properties-->Digital Signatures-->Details-->View Certificate-->Details-->Copy to File (Then follow the prompts of the wizard to save a .cer file) Once you have the .cer, you can import it to the Trusted Publishers node within a GPO and create a software restriction policy using the cert, setting it to unrestricted.

We have a similar Software restriction policy in place and an unintended consequence was that Dropbox failed to run. Our work around was to take the digital certificate that Dropbox was signed with, export it, then import it as a "Trusted Publisher" within the same GPO that our Software restriction policy was defined in, which I believe, automatically creates a certificate based rule under the software restriction-->Additional Rules node in the GPO and sets it to unrestricted, but I might have also done that manually - it's been a while. After that, Dropbox ran just fine. So if "irsetup.exe" is signed, you can use a certificate rule and set it to "unrestricted". If it's not signed, I think you can also do a hash rule. Check the section about rule precedence on this page and I think you'll get it: Using Software Restriction Policies to Protect Against Unauthorized Software

Hmm, could you setup a virtual environment with a "virtual network" and let the kids play around with a VM that's less restrictive?

I guess I'd look at the SCEP config within SCCM for clues on why Chrome might be effected. Maybe create a new client configuration within SCCM where the SCEP settings are left to absolute defaults, apply it to a test system and see if Chrome behaves. If it does, look more closely at the SCEP related setting previously applied in the SCCM client settings.

Good advice from Seawolf there. If you have the resources, I recommend taking a full backup of the entire mess and setting it aside before you do anything. You'll always want to have a way to walk back from a botched attempt at something like this. Just a tip, in the past, when I've migrated shares from one server to another, I've communicated a bit with the users, then set the "old" shares to read-only while I worked on migrating data to the new shares, updating logon scripts to disconnect from the old share to the new etc. That way things are "frozen" a bit, but you're still allowing users access. Knowing how to use robocopy or even xcopy with it's various flags can be really useful for situations like this. Thinking more long term though, I would probably want to figure out a structure that is more manageable rather than take a rats nest off of an NAS and plop it down onto a new one. We have just one share "\\FILESERVER\Departments$" With subfolders beneath that for each department, and permissions set for subfolders by security groups. So there would be a folder for "English" and a security group in AD "ENG_Users" that had all of the English faculty as members with everyone in that group having Modify level permissions to the root of the departmental folder. Then if the department needed a subfolder further restricted, say for the department chair and his/her staff, create a subfolder with unique permissions called "ENG Office Only" and a security group populated with the subset of users you wanted. We're currently using a Win2k8 R2 server with the File Server Resource Management Role and tools, so implementing disk quotas and monitoring it is pretty easy. I'm dealing with Windows Server and an Active Directory infrastructure to handle all of this though. I realize you're talking about using a NAS, so maybe none of this applies.

A bit more info: To grab the MSI from the Java installer: 1. Download the latest offline installer from Java Downloads for All Operating Systems 2. Double click the installer to get it started, but don't finish it. It should extract the MSI and cab file to a directory under: "%userprofile%\Appdata\LocalLow\Sun\Java" Copy the directory to an alternate location and exit out of the installer. Once you have the .msi, you can decide how you'd like to deploy it.

You can also use a GPO to deploy the MSI, (installs upon startup) which is what we do normally. I will warn you though that a small percentage of systems seem to fail an update when pushing the Java MSI using GPO. Thank Oracle for that. Usually using the Windows Installer Cleanup utility (detect and remove previous Java elements) will correct the issue. Sometimes that fails and I have to dive into the registry (usually there's a leftover subkey related to Java under Computer\HKEY_CLASSES_ROOT\Installer\Products\ that prevents proper installation of a new version) a bit and delete a key.

Like @cooka said, if the printer is shared out from a server, you should be able to adjust the defaults server side and they'll trickle down to the clients. Usually (on the server) right click the printer in question, "Printer Properties"-->Advanced Tab-->Printing Defaults button. From there, things will look different depending on the driver being used, but there's usually a place to set the default paper size. Also, random thought, but we've seen in the past where certain printers (HP printers mostly) will attempt to detect what size paper is in a particular tray by where the paper guides in the tray had been pushed. Someone could have gotten a little careless when refilling the tray and moved that guide to an undesired paper size, which is sometimes reflected when you go to print in an application.

One more thought. If your users are new to the concept of not being an admin all day everyday and you are now trying to lock that down, you had better have a method of remote support figured out. Whether its built-in tools like remote assistance/remote desktop (can be configured via GPO) or a third party tool, make sure you have one and that you and your technicians can use it on a moment's notice. I've found that users very much dislike not being an admin (because they don't understand the reasoning behind it and assume you're just doing a power play) and will look for any opportunity to say, "Look, I wasn't able to present at this conference because I couldn't install XYZ and YOU couldn't help me over the phone! I need to be an admin!!!" If you have a remote support tool and plan in place, you can be Jonny-on-the-spot and take care of those things and keep the complaints to a dull roar. You had also better have an idea on how you're going to automate non-Microsoft application updates (like Java, Adobe, etc) because those applications nag the heck out of users each time they have a patch and they will in turn nag you and question your admin policy if you can't patch in a timely manner. So have a method (SCCM, GPO Software push, something) figured out for those things as well.

Similar to @JonDaviesBourne, we don't allow our faculty/staff to be local admins with their domain accounts. However, for those individuals or situations where someone absolutely must have an admin account, we create a separate local admin account, specify a complex password and then show them how to use that set of credentials from within their (non-admin domain account) logged-in session. This protects the system from executing "drive-by" malicious code with admin credentials because the user logs in everyday with their non-admin account, and thus, most software that is targeted for malicious code/exploits (browsers, browser plug-ins etc) is running with the non-privileged credentials. Armed with an admin account, they can do little updates/installs when prompted by using ".\LocalAdmAcct" and the password. Yes, they can also run "CouponPrinter.exe" with admin credentials and hose their system, but surprisingly, that doesn't happen as much as you'd think. Obviously, there are systems and situations where you absolutely should not give local admin access (systems with sensitive data) but that's up to your judgement. You can define what accounts should be in the local administrators group in a GPO here: Computer Configuration-->Policies-->Windows Settings-->Security Settings-->Restricted Groups-->Group (BUILTIN\Administrators (Then populate the members). Another thing that strikes me from your initial description is that you were describing a scenario where you wanted to have a subset of machines that had somewhat less restrictive group policy settings than others. The easiest way to accomplish that would be to plop that subset into a SubOU of their current OU, define a GPO for those systems and then apply it to the SubOU. Remember, the GPO applied "closer" to the object (the computer accounts in AD in this case) should take precedence (unless "Enforce" was used on a higher GPO) if there's a conflict between GPO's.

I've only just started messing with SCCM2012, but I've found that using a GPO to enable the proper firewall exceptions on the clients (you can go port by port, protocol by protocol - there's a darn long list - but just opening up all traffic between your clients and the IPv4 and IPv6 address of your SCCM server is easiest...) as well as the installation of any necessary certificates (will vary in different environments) is the key to getting the client installed as well as ensuring all console related tasks actually effect your clients. Just as a sanity test, disable the Windows firewall on one of the troublesome boxes and try pushing the client again. If it works, then you'll be working in the right direction and can figure out the necessary firewall exceptions. Don't ignore certs either.

It sounds like you're not getting an IP then. Have you tried booting on a different piece of hardware - one that perhaps has a different ethernet card? Just judging by what you've written so far, it sounds like you may have introduced a non-working driver into your boot image, but that shouldn't effect ALL hardware, only hardware with the ethernet controller that suddenly prefers the bunk driver. I'd also try getting back to basics - on a working system that's on your domain, drop to command line and ping your deployment server. If you get replies, next try this from command line, net use * "\\YOURDEPLOYMENTSERVERNAME\deploymentshare$" If you can connect to it, then that at least tells you that there's nothing wrong with your sever or deploymentshare from a network perspective or a windows share/permissions perspective. Then you can safely turn your focus back onto your drivers within MDT, regenerate your boot images, and so forth.

The sooner you dig into MDT the better. I understand that you're in a time crunch, so do what you have to do, but once you understand the basics of MDT, you'll find that your life has gotten a lot easier. WDS just really augments the deployment options you have via the "work" you put into MDT. I prefer the "thin" image approach nowadays. I used to do a hybrid approach, but I've found that creating, capturing and deploying custom .wim's is time consuming and can lead to inconsistent deployments over time. With the "thin" approach, I simply deploy the unmodified Win7SP1 x64 Enterprise .wim and put all of my "work" into the applications node of MDT. If you can figure out the silent install command to each of the applications you intend to have be part of your standard deployment, then you're 80% of the way there. The rest of the "work" is figuring out how to adjust defaults per application during install (using Orca to generate MSTs mostly) and then using batch files, scripts etc to do cleanup, place shortcuts etc. Once you've put the work in to figure out how to smoothly deploy an application (Java Runtime Environment, MS Office, Adobe Flash, VLC Media Player and so on...) you won't have to put much thought into keeping your deployments current because the method to install say, Adobe Flash for IE version 13 is usually exactly how you'll do version 14... Get a list of apps working in MDT then create an "App Bundle" to deploy them all with one checkbox during Lite Touch. Yes, there's a learning curve, but the payoff is huge. Just my two cents.