5 Replies Latest reply on Jul 28, 2006 1:22 PM by Ming Wu

    Provisioning Dell 1850 strangeness

    Erik Johannessen

      Has anyone tried to provision a Dell 1850, with Perc4/SI raid controller?


      We are trying to get windows 2003 provisioned on one, we have downloaded the raid controller driver from dell, added it in 1850/$OEM$/textmode directory, then added the entries and the entries.


      So windows install happens, it does the reboot, starts installing windows, comes to the 'starting windows' part, and it errors, saying something like.


      'The manufacturer hardware driver is corrupt' 'Syntax error on line1' 'hit F3 to reboot'


      Has anyone seen anything like this ? Did I mess up somewhere? The driver consists of some .inf files, a .cat file, 2 .sys files, and a 0byte file called 'mraid' (no extension) - I'd really like this to work - so any help would be great.

        • 1. Re: Provisioning Dell 1850 strangeness

          its been done, though i don't have the specifics surrounding it. check to see if the driver set you're using are specific to windows 2003 with or without the service pack... you might also have luck applying the same logic used for the dell poweredge 2850 servers which are also discussed in the KB and forums.

          • 2. Re: Provisioning Dell 1850 strangeness
            Erik Johannessen

            To answer my own question, after a good day of troubleshooting this -


            The trick is to make sure you have the xcopy32.exe, xcopy32.mod and xcopy.exe from the externel-files.tar bundle, as soon as we put that into place, it all worked.

            • 3. Re: Provisioning Dell 1850 strangeness

              Do you have any more details on how the copy may have corrected the problem? I'm trying to do the same using windows 2003 on a dell 1850 with the PERC 4e/Si controller. I've tried both the latest driver as well as the one referenced in the 2850 provisioning document (revision A04).


              It turns out that there may be some syntax issues in txtsetup.oem provided by the driver -- apparently, if the drive is formatted as fat32, you need to change the text section to use "." instead of "\" at the end. However, after doing that, I am able to bypass the syntax error but then it complains about being unable to find the driver


              \$WIN_NT$.~BT\$OEM$\.\MRAID35X.SYS (Error code 18)


              I've checked for case sensitivity, so the filename / pathname doesn't appear to be the problem, and I've also verified that


              C:\$WIN_NT$.~BT\$OEM$\MRAID35X.SYS does exist. I would think that the two paths are equivalent. I've also tried some other tricks that I've seen online, but only end up with syntax errors in the process.


              If anyone has any thoughts on this, I'd appreciate it. I'm spent hours combing the forums, kb, and other online resources as well as brute force trial and error.


              Attached is the section in my txtsetup.oem that appears to be causing the majority of the grief:


              PERC32 = "DELL PERC RAID Products for Windows 2003 (x86)", \mraid,\


              I changed this to


              PERC32 = "DELL PERC RAID Products for Windows 2003 (x86)", mraid, .


              If you remove the "." from the end, or try to replace it with empty quotes (""), it throws a syntax error, so this is the only syntax that appears to not throw an error.

              • 4. Re: Provisioning Dell 1850 strangeness
                Erik Johannessen

                The xcopy fixes the problem, because the oemsetup.txt file and unattend.txt file that gets copied over with the wrong version of xcopy gets corrupted.


                I saw the exact same thing you did by adding the \ to the path, so I think if you copied in the right xcopy files, it should work great.

                • 5. Re: Provisioning Dell 1850 strangeness

                  Thanks for your help - the xcopy wasn't corrupted -- in fact, it didn't exist! I was using a non-standard datastore and didn't realize I had to copy the files from /pxestore to the root level of the new data store. I noticed the problem when my other Virtual server installations were failing and I saw that it was trying to run bmiwin.exe from the new datastore.


                  Be sure that if you create a new datastore, you mimic the format and files of the original datastore.