Friday, 19 August 2011

Dell Optiplex 390 fails to apply GPO settings


At work we have been deploying Dell Optiplex 390’s with XP using an MDT task sequence, the build works perfectly however once the machine attempts to apply group policy we have failures, this causes the machine to fail to install allocated msi packages. Obviously not a great situation to be in.
Following some research I have found that the issue appears to occur mostly in situations where a client is using a Gig speed network card and where network connections are teamed. The issue appears to be caused by the network card switching between speeds and full/half duplex to find the mode it can operate at. By adding a registry key we can prevent this checking from happening which will provide a more stable connection during the all important startup process.
This solution has been tested to work in our environment, obviously your mileage may vary and if you choose to make this change you do so at your own risk, playing with the networking settings in Windows may break more than it fixes however in our testing this has been an easy and successful workaround.

The key details are as follows
Key Location : HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
Key Name : DisableDHCPMediaSense
Key Type : Reg_Dword
Key Value : 00000001

These settings can either be added using a reg entry or a command line as follows
reg add HKLM\System\CurrentControlSet\Services\Tcpip\Parameters /v DisableDHCPMediaSense /t REG_Dword /d 00000001

In our case we have added a command line near the end of our task sequence which we have filtered using WMI in a way similar to the one we used in a previous post. In this case the WMI filter we used is as follows


Select * from Win32_ComputerSystemProduct WHERE Name LIKE "%Optiplex 390%"

Again we are running this against the root\cimv2 namespace. This query could be repeated in the task sequence options filtering for additional hardware which exhibits this particular issue, thereby allowing you to keep a smaller number of task sequences in your deployment share.

Update : 29-06-2012

We have begun rolling out Samsung N200 laptops, these also exhibit the issue with needing DHCPMediaSense to be set, for ease of use here is the WMI code needed

Select * from Win32_ComputerSystemProduct WHERE Name LIKE "300V3A/300V4A/300V5A/200A4B/200A5B"

Reference:

Technet User Discussion

Serverfault Question

14 comments:

  1. Thank you. Solved the exact same problem for me.

    I've seen this before with Dell Vostro PCs (and built in Realtek network interfaces), and managed to fix it by trying different versions of the driver. I didn't manage to find a version of the driver for this system that would work though, but your method worked first time.

    I wonder if this registry change you are using is the same is disabling auto sense on the adapter settings?

    ReplyDelete
  2. I am not sure about this as during my testing I tried forcing the card to use each of the available operating modes, however the same issue appeared.

    This is the only way I have found to get around this problem in several schools but now we have it in our task sequence it makes thing a bit easier :-)

    ReplyDelete
  3. I have a client that is looking for a new Desktop with Windows XP. After doing a little looking, I noticed that the Optiplex 390s have Windows XP drivers available. I figured I would get the PC with Windows 7, format and install XP. But what about the SATA drivers? I didn't see them on the Dell website. I just don't want a client to spend $800 on a computer and I not be able to get it working as he needs it.

    ReplyDelete
  4. We deploy these models with Windows XP on them, if you look on the Dell site you will find an option where you can download both a WinPE and Windows drivers pack.

    These contain the raw drivers in a cab file which we then import into MDT to use with our task sequences, this has worked flawlessly for us on several sites.

    If you are looking to manually use the drivers then I suppose you could add the drivers to the i386 and $OEM$ folders on a custom XP CD, I wont explain how to do this as it has been covered beter than I could explain at this site : http://unattended.msfn.org

    Good luck.

    ReplyDelete
  5. I downloaded the driver cab and unzipped it, but I didn’t see the “F6” drivers. There are 3 subfolders under the chipset folder, but I am not sure if either one of them are the F6 drivers that I am looking for.

    Do you happen to know or can point me in the direction of the SATA drivers that I will need in order to do a single installation of Windows XP on the 390?

    I also took at look at the Precision T1600, and I clearly see the F6 SATA drivers for that particular PC. They are easily located on the regular drivers download page on the Dell website.

    ReplyDelete
  6. Patrick,

    Unfortunately I am not sure about the individual files you will require, the way we deploy XP onto these systems is using MDT, this lets you import the drivers in and works out what it needs for itself during deployment.

    Microsoft have modified the windows installer to work with any drivers included in the deployment share.

    I'm afraid we dont build machines manually any more, are you running these in a network? If you are then it may be worth looking into MDT as a means of deployment, the initial learning curve is well worth it for future deployments as you simply import the drivers for the new model in and boot from the network.

    We will be putting together a basic getting started guide for setting up and deploying windows XP using MDT soon, if you would like to be a guinnea pig for these articles please let me know and i'll see what we can do for you.

    ReplyDelete
  7. You the man!! Been trying to figure this out for a week and a half probably. This solved my problems. I had a feeling it was related to the Realtek NIC. I also couldn't image those via Altiris until I added that NIC to the WinPE preboot, so I was afraid they were going to cause more grief. Our other Desktop Tech found your article and the job has been deployed. Thanks so much for sharing.

    ReplyDelete
  8. Hey, thanks for this post. When I started getting event id 1054 on some newly purchased 390's I started looking toward NIC drivers, but having found none that work I stumbled on this post. Tested on one machine, restarted and it instantly started installing software. I have added the line to our build and am currently building two more to test. We are planning on moving to Windows 7 later this year but this fix has helped me out for the next few months until I can say goodbye to XP.

    Thanks!

    ReplyDelete
  9. Wow, thanks for this, spent all day looking for a cause of this for our Optiplex 390 XP ghost image! Fix works! \o/

    Also oddly seen it on a few Optiplex 380's, even though we have many 380's which work fine from the same image (possibly a slightly different hardware batch) - fix works for those as well.

    Many cheers,

    Ben

    ReplyDelete
  10. Cheers for this, was very helpful

    ReplyDelete
  11. This post was a lifesaver. I was worried I would have to go back to Windows 7 even though XP is better supported in our environment. Thanks again...

    ReplyDelete
  12. Has anyone seen that drive mappings are off? It seems we're getting different user types getting extra or wrong mapped drives. It's on a 390 machine that we used this fix for, as it was the only way to get rid of the 52 and 1054 errors.

    ReplyDelete
  13. Cant honestly say that we have had any issues with drive mapping being off, we have been using this for computers which are used by pupils, staff and admin users with no issues.

    The only thing I can think is that you may have some additional policies applying either to the user or computer as we are using this in excess of 20 sites. Sorry I cant be of more help.

    ReplyDelete
  14. Thanks - worked a treat :)

    ReplyDelete

Please enter your comment here, all comments are subject to moderation