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.

Hey all, I've been running into the same thing (trying to silently install first AppleApplicationSupport then QuickTime, but the QuickTime installer failing complaining about a possible corrupt cab). Essentially, I've done the following on a fresh Win7SP1 (x64) box - downloaded the latest (7.75.80.95) QuickTime installer for x64, extracted it with 7Zip and pulled out "AppleApplicationSupport.msi" and "QuickTime.msi". If you attempt to install first "AppleApplicationSupport.msi" AND suppress a reboot, then install "QuickTime.msi", you get the error about the cab file. If you allow a restart to happen in between AppleApplicationSupport and QuickTime, QuickTime installs just fine. Try manually running these two commands on a fresh Win7SP1 (x64) install with the above mentioned MSI's and I can guarantee you'll get the error. msiexec /i "AppleApplicationSupport.msi" reboot=suppress /qb Then, without rebooting.... msiexec /i "QuickTime.msi" /qb I can pretty much guarantee you'll get the error, which sucks, because in an MDT lite touch deployment scenario, the (apparently necessary) reboot caused by the install of AppleApplicationSupport causes the "Dirty Environment" Y/N prompt after the restart, which can hold up the lite touch process unnecessarily until someone comes by to click "No". If someone can figure out how to install those two things in sequence *without a reboot*, I'll be eternally grateful!

It's not clear to me that disabling IPv6 at the OS level would prevent the NIC from misbehaving when the system is in a sleep state. This seems to be a firmware level issue, though I could be wrong.

A bit more scouring of the net seems to suggest that this problem is seen in other pieces of hardware that have an Intel I217-LM NIC. So it's not just limited to the Dell Optiplex 9020's. https://communities.intel.com/message/220048 ICMPv6 'Multicast Listener Report' messages are flooding the local network

I've read that suggestion and considered it yes, but if we can solve the issue with a BIOS update to the unit, I think that would be our preferred method for now. Long term, it just seems like a less thorny fix. I'll report back after we've investigated the resolution more thoroughly.

I recently ran across a bizarre problem and I thought others might benefit from what we seem to have found. SYMPTOMS: Our initial "symptom" of the issue was an intermittent problem with various networked HP Laserjet printers (specifically LJ P2055DN, LJ P4015DN) whereby they would lock up, stop processing jobs, not even respond to button presses on the front panel. Remove the network cable and BOOM, the printer would begin responding to button presses, menu navigation, could even print out a configuration page. Plug the network cable back in and BOOM, instantly locked up again. Three different printers, same issue. The lockups would eventually subside on their own, only to happen again at a later date. TROUBLESHOOTING: Tried all of the typical stuff with the printers, thinking they were the root cause. Firmware updates, cold resets, different drivers etc. The problem came and went mysteriously. Once we realized that three separate networked printers on the same VLAN were exhibiting the same strange behavior (albeit sporadically) we began to focus on the network. I began working with one of our network admins who asked me to call him the next time we received a complaint with one of the printers, which I did. He was able to observe that two different systems on the VLAN were spewing an excessive amount of IPv6 multicast listener discovery packets during the printer lockup; I believe he said a rate above 16,000 packets/s originating from two separate boxes on our network. Armed with the IPs of the trouble making boxes, I set out to track them down. I expected to find a compromised system or someone using P2P software, maybe a box with Bonjour going nuts with multicast traffic…something. What I found was that the two systems were both relatively new Dell Optiplex 9020’s installed in classroom podiums. That immediately confused me because our classroom systems are locked down (no end users are administrators, managed patches etc) and the deployment applications are plain vanilla! Ran some scans, used some Sysinternals tools to look for anything malicious and/or chatty that would explain the multicast traffic and came up with ziltch. These systems were clean. The network admin had provided me with charts showing when the traffic spikes took place on both boxes, so I decided to check the Windows eventlogs to see if I could find a correlation between the network activity and a user or application. I was surprised to find with 100% certainty that as far as Windows was concerned, both systems had entered a sleep state for the entire duration of the IPv6 multicast listener discovery packets. It wasn’t even close really, both systems had gone to sleep and remained asleep during the whole thing. A quick google search of "optiplex 9020 sleep multicast" turned up several posts from around the web reporting the exact same behavior. Opti 9020s with Intel I217-LM nics causing network issues - Desktop General Hardware Forum - Desktop - Dell Community Dell Optiplex 9020 blasting "ICMPv6 Multicast Listener Discovery during S1 sleep - Spiceworks The Dell Optiplex 9020 DDOS ICMPv6 Multicast Listener Discovery - [H]ard|Forum CONCLUSION: From what I gathered from reading, Dell Optiplex 9020 systems with the Intel I217-LM NIC with a BIOS revision prior to A05 were exhibiting this strange behavior – randomly flooding the VLAN with IPv6 multicast traffic for a period of time while the systems were in a sleep state. This past summer, we had purchased Optiplex 9020’s to replace all of our classroom podium systems (about 30 in the building that had the printer issues, all on the same VLAN). I can’t yet confirm that upgrading to A05 will correct the problem (just figured this out with the network admin this morning) but others have seen some success. They do mention thought that WOL doesn’t work in A05. SUMMARY: If you’re experiencing unexplained lockups or sluggish performance from networked devices like printers, access points, NAS’s etc, have a network admin check for unexplained IPv6 multicast traffic, especially if you have Dell Optiplex 9020’s (possibly other devices with an Intel I217-LM NIC) on your network with an early BIOS revision as they may be sporadically spewing IPv6 multicast traffic (while in a sleep state) causing adverse effects on other devices.