bbrook

Hi guys. We got this sorted - sort of! After a few extra settings changed on the group policy (point and print restrictions disabled) this seems to have improved things. I'm reimaging the entire network during the Summer so will be testing this a bit further as well. I'll keep you posted.

We've got a network of Windows 7 PCs all joined to a domain with Server 2008R2. I've set up a user group policy object that does the following: Delete all shared printers Add each printer in turn, setting a single (dummy one) as a default This is via the Preferences > Control Panel Settings > Printers option. When users logon it appears to be entirely random whether or not they get those printers added. Checking event viewer on an affected logon, Group Policy Printers reports the following error: Group Policy object did not apply because it failed with error code '0x80070704 The specified port is unknown.' This error was suppressed. If I then try and perform a 'manual' setup by typing the server hostname and printer share into Explorer I get the same error 'The specified port is unknown'. I thought I'd fixed it by changing the GPO settings to map printers using the server IP address but the issue is still occurring. I've also tried using a new, untouched profile with the same results. As I'm sure you'll all understand this is becoming more than a little frustrating now, especially when there's no apparent logic to it. Any thoughts on the next step of diagnosis? I've taken a brief look at the DNS servers thinking that might be the issue before I used IP addresses and run a dcdiag DNS test and all passed. I should also point out that the whole room received the same windows image and have the same driver versions installed. All help very gratefully received!

I've hit a snag with my MDT 2010-based deployment. I deployed a modified Windows 7 image yesterday no problem. I've since made some changes to the image, captured it and placed it into MDT 2010. I've created a new task sequence (Standard Client Task Sequence) and made slight modifications to the unattend.xml file (set locales in oobeSystem and remove the Display key in oobeSystem as I'd rather it auto-configures that part). The deployment works fine and according to BDD.log it sets the install phase to STATERESTORE, but then copies the LiteTouch.lnk file to the root of C:\ rather than the shared Start Menu\Start Up folder. This means the PCs reboot but the LiteTouch task doesn't continue without some intervention (namely running LiteTouch manually from C:\) Not a huge show-stopper but an inconvenience if I want a near-completely non-interactive deployment. Any ideas where to start looking?

Not one I've heard of before, but like a lot of strange permission-related problems I've had in the past, have you tried repairing permissions through Disk Utility (/Applications/Utilities/Disk Utility - though you'll need to be logged in as a local admin account if you can't access the Applications folder)?