Video Screencast Help

Need help changing from DOS to Win PE

Created: 04 Dec 2012 • Updated: 13 Dec 2012 | 8 comments
This issue has been solved. See solution.

We have finally hit the point where we need to change from our DOS boot to the WinPE. We are currently using Ghost server 11.5.1.2266. Right now, we have 6 stations connected to a switch where we can connect to the ghostcast server. No router is in the picture. Currently we use the PC DOS boot option. We have several USB flashddrives for specific NIC and Storage Drivers (we are a Dell Shop). We use static IP so each USB flash has its own assigned IP. (I believe the file we edit is called WATTCFG, or something like that) We then use the multicast option.

I can't seem to get this to work in WinPE. I have made sure that the NIC drivers are selected in the Boot Wizard. I put my static ip info in. It boots fine. However, I can not connect to the Ghostcast server. I can not ping the server. If I do an ipconfig, I get no information.

Any ideas would be appreciated.

Thanks!

Comments 8 CommentsJump to latest comment

EdT's picture

First of all, are you adding Vista 32 bit drivers to your WinPE boot image?  WinPE is based on the Vista 32 bit kernel so needs Vista 32 bit drivers, and NOT drivers for the operating system you are imaging. The lack of IP information suggests that the NIC driver is not working.

Also, DELL use Intel chipsets in many of their machines, so check whether the NIC chipset is the 82579, and if it is, enter 82579 into this forum's search engine, and follow any of the links to working drivers that other users have found. Not all drivers available for the 82579 work with WinPE.

Finally, if you are using Multicast, make sure that IGMP snooping is enabled on your switches otherwise you will find that the imaging process fails after 3-4 minutes.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

SOLUTION
SarahA's picture

Do you need to enable igmp snooping if there is no router involved? We were able to multicast with the DOS boots. Would this need to be changed for WinPE?

I may take awhile to mark best answer. I need a vacation :) But I appreciate the help!

EdT's picture

I can only go by the numerous postings made by former Ghost developer Nigel Bree, who has explained at length about multicasting, IGMP snooping and other related networking issues.

Here are a couple of clips I have kep on file:

 

- You absolutely should have "IGMP snooping" enabled on all the managed switches in your network which can support it, because without this the switches emulate the behaviour of classic IEEE 802 Ethernet in respect to multicast frames, which is to broadcast them. You DO NOT want this if you have applications which use IP multicast heavily. Enabling switch-level IGMP support brings the efficiency benefits of IP multicast down to the level of switch ports, and in particular allows the switches to avoid distributing multicast frames to switch ports which are in low-power states, where it is common for the port to be autonegotiated to a 10mbps speed.

- "IGMP snooping" is a switch concept which is not a part of the IGMP protocol or the IETF IP network architecture; IGMP snooping in switches instead piggybacks on the IGMP protocol, which is a protocol conceptually provided by routers in the IETF architecture - when this snooping is enabled, switches (which are really point-to-point routers that are emulating a broadcast bus) then use that routing information to determine how to route frames to their individual switch ports.

- The part of the IGMP protocol provided by routers is called IGMP querying: in order to work correctly, IGMP snooping requires at least one active IGMP querier to be servicing the network segments covered by the switches. This can be provided by a router, and the majority of modern managed switches can also provide this capability.

- Although the IGMP protocol specification details techniques by which multiple queriers vote amongst themselves (by IP address) to ensure only one query source at a time is active, some switches have appeared to not honour this part of the IGMP specification properly. See for instance https://www-secure.symantec.com/connect/forums/ghost-115-flooding-our-network and so some care may need to be taken in selecting which device(s) have IGMP query generation enabled.

- Sometimes, dedicated routers or devices such as managed switches with routing functions do not have a particular configuration setting for generation of IGMP queries. On such devices, IGMP query generation is implicit, and enabled by the configuration of inter-router protocols such as PIM. So, depending on your vendor it may or may not be necessary to configure PIM support on some device(s) to ensure IGMP query generation. Enabling PIM may have some consequences beyond the local switched network, however, so if you are considering this it's generally a good idea to read your vendor's documentation thoroughly.

Note there is nothing Ghost-specific about any of this; IP Multicast is a standard part of the IETF network architecture and has been since about 1989, while the "IGMP snooping" extensions to switches (which piggyback on the IETF standard IGMP protocol) have been defined by switch vendors and all have basically worked the same way since the mid-to-late 1990's. It simply happens that since Ghost's protocol code was written to the IETF multicast architecture but before IGMP snooping became a widely deployed technique, it's not designed to cope with the hard-to-detect failure modes resulting from incorrect network configuration due to not installing an IGMP querier. Unfortunately, since Ghost is also one of very few applications (other than telephony) which makes extensive use of IP multicast and offers significant network load, it's generally the only thing on many corporate networks which is sensitive to the network's multicast configuration.

When a switch is configured to use IGMP snooping but no IGMP querier is present, the most common presentation is that a networks on which IP multicast appears to be working perfectly for a short time suddenly stops working altogether as the switches time out and unilaterally block delivery of multicast traffic to their ports. Because the switches do this without issuing any advice or control traffic to anyone and because the TCP/IP stacks in operating systems do not provide features for applications to detect whether an active IGMP querier is present, detecting this failure mode automatically is hard (and when it happens, there is very little that applications can do about it).

IGMP Snooping

Ghost uses IPv4 standard multicast; a great many switches are not configured correctly for this extremely simple part of standard TCP/IP networking, but every switch vendor has documents explaining this and how to configure it, and I've written many dozens of posts here on these forums on the topic of configuring switches for this.

Basically, the problem is a switch feature called IGMP Snooping - IGMP is a standard protocol used to communicate with routers that Ghost uses in a perfectly standard way. Since modern switches are only *emulating* classic Ethernet, they really behave more like routers, and IGMP Snooping is a technique the routers employ to piggyback on the actions of real routers to efficiently deliver multicast traffic to only the switch ports that subscribe to it.

However, to use it you must also have the network enabled with the proper router support - in particular, having a router or similar device generating standard IGMP query traffic; without this, the router is aware of machines initially subscribing to multicast groups but then times out those associations after a few minutes, which leads to precisely the symptoms you describe.

Exactly how to correctly configure this depends slightly on what network equipment you have, but all the switch and router vendors have extensive documentation on how to do this properly. It's a simple process which may just be a matter of changing one configuration either in your routers or switches.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

funguy's picture

Have no fear when leaving dos behind.  I recommend you build your own custom winpe based on make-pe3.  Updating constantly for each new driver can be a pain using the ghost boot wizard version.  Here is what I do: https://www-secure.symantec.com/connect/forums/boot-disk-windows-7-professional-64bit but I also have a linux one that is faster and easier for newbies..http://forum.tinycorelinux.net/index.php/topic,12613.msg76701.html#msg76701 .  winpe is sloow to pxe boot because it needs more files but very robust using driverpacks, but my linux one is only 28mb and loads almost as fast as dos.

SarahA's picture

I really like your type up there for the winpe. But what I'm having a hard time following is the driver packs. How will I know DriverPack Chipset 12.06 for Windows Vista/7 (x86) contains the drivers I need for my dells? I went to dell to look for driver packs and they have a big one for WinPE3 and each individual pc that we have in the shop. But thats way more than I ever need. I could download the nic, chipset and mass storage one at a time, but that would take forever too.

EdT's picture

You may therefore be interested in another of my articles:

https://www-secure.symantec.com/connect/articles/r...

Run this on any new PC that comes into your company, and you then have a text record of all plug and play device IDs used in that system.  Pick out the device IDs associated with your NIC and SATA hardware.

When you download a candidate driver, you will need a .INF, .CAT and .SYS file as a  minimum. The INF file lists all device IDs that are supported by that driver, so you can quickly check if your hardware is supported.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

funguy's picture

We beta test unreleased hardware for dell and hp and the driverpacks from driverpacks.net are surprisingly robust.  You know its in there if ghost works.If it isn't in there I just wait for new driverpacks.  I think they have a tutorial on adding more to each but I never have that problem. Since driverpacks.net uses torrents to distribute I still recommend getting the x86 and x64 for nic, mass storage, and chipset.  They download fast.  Plus the disk you make is 32bit (for compatibility) and the modded fix_7HDC.bat can still fix both 32 and 64bit machines as long as you added all related packs.

SarahA's picture

Thank you both for your help! I have learned alot about making my own win 7 PE and will be tinkering in the near future.

For now I have got my original WinPE working by getting rid of the static IP addresses! I forgot all about IANA! Since our ghost area is just an isolated segment with no router, I let IANA do all the work by enabling DHCP on the ghostcast server. I had noticed after getting the right windows drivers (Vista) I was getting IANA addresses. So I thought I would just go with it instead of fighting with the static IP.

Thank you all again!