ChrisBaksa

Has anyone had any sucess in installing Microsoft Dot Net 2.0 into WinPE? I have a need to compile PE and it requires Dot Net Frameworks 2.0. If anyone has done this could you point me in the right direction. Chris

The Boot Loader Text can be changed by modifying the CONFIG.INF file. Chris

I have found absolutely no reason to move to WinPE 2.0. WinnPE 2005 is rock solid and has driver support for everything I need. With the scripted builder I wrote, I can build a WinPE 2005 image in about 90 seconds. There is nothing in WinPe 2.0 that I can't do in WinPE 2005. (at least nothing that I have found that really matters to me) In general... WinPE 2.0 seems to be more of a headache then it's worth. My 2 cents. Chris

One way to do it is to use pcAnywhere. pcAnywhere has a Thin Client that will load under WinPE. Of course... this is a 3rd party app and requires purchase. But if you have it. It works Well. I can tell you that the thin client is a compacted EXE that extracts files when executed. So you have to make sure the exe is on a Ram Disk. The User ID and Password are compiled into the EXE. Chris

The answer in a nutshell is Yes. I have 2 PE images booting off Linux. 32 and 64 Bit Versions of PE. I'm using PE 1.6 (or PE 2005 as they call it). Chris

32 Bit CD - Stand alone CD with tools/scripts/drivers/applications for 32 bit OS's (desktop and server) 64 Bit CD - Stand alone CD with tools/scripts/drivers/applications for 64 bit OS's (server) - Unattend 64 bit OS installs 32 Bit Image for PXE - Fully scripted (automated) image on the PXE server for 32 bit OS's - no user interaction at all. 64 Bit Image for PXE - Fully scripted (automated) image on the PXE Server for 64 bit OS's - no user interaction at all. The PXE images are smaller. All tools are network based where as teh cd images have alot of tool on the cd. Keep in mind that I don't do image building yet. And I cannot use any of the "Hacks" for installing a 64 it os form 32 bit PE. If it's not supported by Microsoft. I cant use it. Chris

I thought about that. Making that function would be the easiest. But I'd rather not gen a new version of PE. It gets tedious when you have to manage multiple versions and keep up on driver changes/updates/additions. I have 4 versions as it is (32 bit CD image, 32 bit PXE image , 64 Bit CD image, 64 bit PXE image) Thanks for the suggestion. Chris

In a perfect world... a setup process wold be nice. But my issue is I must cover all angles and protect data at all costs. I can't rely on the SA's doing manual configs and a remediation project to correctly configure hundreds of servers globally would be a nightmare. My goal was to pose this question and let people who have addressed this already comment. This way I can review the comments and engineer a solution into my environment. I only previously supported SAN after the OS was installed... so this is new unchartered territory for me. I have to proceed very cautiously. Chris

This is Difficult to explaine. Currently, my Server build checks for a valid disk parition on the boot device (I don't deal in actually creating raid containers as there are way too may configurations, hardware models and vendors). In most instances that partition is found on the servers Local Raid Controller. But if the fiber drivers are on the PE disk and the fiber card is set to boot, the the disks on the SAN are seen as the boot device. Now the complext part. All my current servers in production that are SAN connected but boot from the Raid Controller. Almost all have the default Fiber card setting of Boot. Since my PE cd does not have fiber drivers, it was never a problem. It cant see the SAN anyway. Now I would be introducing the drivers back. If one of the existing servers needed to be rebuilt, the SAN data would be destroyed as the SAN would be seen as the 1st valid disk because the fiber card is set to boot. So how do you overcome this? Thats my problem.

Hello all, I am posed with a situation and was wondering if anyone has delt with this already. I have been asked to do a build of Windows 2003 Server using EMC SAN Storage as the Boot Device. At this time, I have all the drivers for Fiber Cards removed from my PE Build. I would have to put them back and I'm not too happy about that as it can be very dangerous and very unpredictable. My biggest problem is that an Emulex (or Qlogic) cards default setting out of the box is Boot. And no one really bothers to change it. With that said, it's not the new installs I'm worried about.. it's the existing servers that could possibly be re-built or recovered. Basically, if the fiber card driver is loaded, and the card is set to boot..... say bye bye to the data on the SAN even if that was not your intention. So you see my dilemma, but now is the bigger question.... How do you address it? My biggest concern is protecting existing data on the SAN. Comments... Suggestions... Idea's Chris

Has anyone dealt with System partitions? I have several peices of hardware that require system partitons (older hardware but we stil use it and I have to support it) My issue is that the System partition is a hidden partition with no drive letter assigned. ImageX can't deal with this partition like PQIDeploy or Ghost. Has anyone been sucessful with imagaing and deploying a system partition using imageX? I am told I have to play with it by actually making the sys partiton active and assigning a drive letter Then Imaging it. And when I deply it.. doing the same in reverse. Deploy as C:... then hide it and mark as non bootable. Thats lot of work in my book.... I'm curious if anyone has tackled this yet and if they would post the code thay used. Chris

Yes... cut from the Docs... <snip> Windows PE Limitations Windows PE is a subset of Windows Vista, and has the following limitations: To reduce its size, Windows PE includes only a subset of the available Win32 APIs. Included are I/O (disk and network) and core Win32 APIs. To prevent its use as a pirated operating system, Windows PE automatically stops running the shell and reboots after 24 hours of continuous use. Windows PE cannot act as a file server or Terminal Server. (Remote Desktop is unsupported.) Distributed File System (DFS) name resolution is supported for standalone roots only. Domain roots are not supported. The tested methods of gaining network connectivity to file servers are TCP/IP and NetBIOS over TCP/IP. Other methods, such as the IPX/SPX network protocol, are not supported. All changes that you make to the Windows PE registry while running Windows PE are lost the next time you restart the computer. To make permanent registry changes, you must edit the registry offline before starting Windows PE. Drive letters are assigned in consecutive order as you create partitions in Windows PE; however, the driver letters are reset to the default order when you restart Windows PE. Windows PE does not support the Microsoft .NET framework or the Common Language Runtime (CLR). Windows PE does not include the “Windows on Windows 32” (WOW32), “Windows on Windows 64” (WOW64), Virtual DOS Machine (VDM), OS/2 or POSIX subsystems. To install a 64-bit version of Windows you must use a 64-bit version of Windows PE. Likewise, to install a 32-bit version of Windows you must use a 32-bit version of Windows PE. Windows PE can be used to configure and partition a computer's disks before starting Windows Setup. If any hard disks are converted to dynamic disks with Diskpart.exe before you start Windows Setup, then those hard disks are recognized as foreign when the operating system is installed, and any volumes on those hard disks will not be accessible. Windows PE does not support applications packaged with Windows Installer (.msi). Windows PE does not support 802.1x.

Why is it that everyone uses Diskpart to format/partion etc when WinPE has the built in capability already? This is what I use in my WinPE 1.5 winbom.ini file... [DiskConfig] Disk1 = Disk1.Config [Disk1.Config] WipeDisk = Yes Size1 = * PartitionType1 = Primary FileSystem1 = NTFS QuickFormat1 = Yes SetActive1 = Yes All of this and MORE are documented in the winpe.chm file found on the WinPE disk... You are 100% correct in your statement. However... this is only feasable if this is your ONLY config. Many of us require custom created partitions based on different criteria (machine model, Application profile...etc). DiskPart is one way to do it. Personally... I find diskpart very user un-friendly and tedious which is why we have opted to write our own command line driven tool which is 100% more effecient/powerful than diskpart. I simply can't be bothered with creating input scripts. Command line parameters are so much easier to deal with and require much less code to manage. Each to his own I guess... Chris

Does anyone know of a 64 bit version of GREP that will run under WINPE? I have been unsccessful in finding grep in a 64 bit command line tool. Thanks Chris

VB works fin in PE. Very simple to install. (extract and copy the files) Word of advice... If you have any plans on using this under 64 bit PE. Stay with C++. The VB runtimes are 32 bit and 64 Bit PE does not have a 32 bit subsystem. I had to have all my VB tools re-written in C++. Chris

Suggestion.... Scrap the HTA. Write yourself a small app (exe) that does it all. The app that we wrote can read from teh DB and write to it as well. Chris

Have you looked at IBM's Windows PE toolkit? That might give you your answer. Chris

Adding NEW drivers is easy. The doc tells you how to do it by modifying the winpeoem.sif and copying the F6 Disk to the folder specified. Here is an example... [OemDriverParams] OemDriverRoot="drivers\additional_oem" OemDriverDirs=INTEL_SATA_82801FR, HP_SAS The tricky part is actually replacing an existing driver with a new one. 1st you over write the origional driver with the new driver. Then you edit the txtsetup.sif file and add the new PNP\VEN ID's for the new hardware and bind it to the driver. If you don't do this... you will never load the driver for the newer hardware that that driver supports. Ex... HP Smart Array 6400 controller. The out of box driver does not support it. Replace the driver with the new one and get the PNP\VEN Strings from the INF file and add them to the txtsetup.sif. Ex: PCI\VEN_0E11&DEV_B060&SUBSYS_40700E11 = "hpcisss" PCI\VEN_0E11&DEV_B178&SUBSYS_40820E11 = "hpcisss" PCI\VEN_0E11&DEV_B178&SUBSYS_40830E11 = "hpcisss" PCI\VEN_0E11&DEV_B178&SUBSYS_40800E11 = "hpcisss" PCI\VEN_0E11&DEV_0046&SUBSYS_40910E11 = "hpcisss" PCI\VEN_0E11&DEV_0046&SUBSYS_409A0E11 = "hpcisss" PCI\VEN_0E11&DEV_0046&SUBSYS_409B0E11 = "hpcisss" PCI\VEN_0E11&DEV_0046&SUBSYS_409C0E11 = "hpcisss" PCI\VEN_0E11&DEV_0046&SUBSYS_409D0E11 = "hpcisss" PCI\VEN_0E11&DEV_0046&SUBSYS_409E0E11 = "hpcisss" Chris

Use the following as a tempate... The Intell driver uses more than just the sys and inf files. Copy *.sys to \i386\system32\drivers Copy *.dll to \i386\system32 Copy *.exe to \i386\system32 Copy *.din to \i386\system32 Copy *.inf to \i386\inf Chris

Is there any secret in getting 32 bit apps (mostly command line tools) to run under 64 bit PE? They work fine under a 64 bit OS so I guess it has something to do with how PE calls it. I've tried running Postie.exe (32 bit smtp mail app) but it simply does run run. I even tried putting the file in teh syswow64 dir. Anyone? Chris

Thanks... I'll talk to my TAM. Chris

This is a VMWare session? (I think you said that) Check the Boot Order for that session. I remember haveing a boot order issue with VMWare where it would hang. Chris

This more a limitation of the manufacture's tools not PE. I can tell you that HP is working on making the Softpaq's run under PE. Currently thay have a hard coded dependency on a drive location. What I have done is put the OS on the host 1st and then run the Flashing tools under the Installed OS. This way my code is common. All the manufactures that I support (HP, IBM, Dell) can flash under Windows 2000, 2003) Chris

Not sure if this have been answered yet... Can someone tell me how to break out Ximage form the Vista CD's? I'm just starting to look at it. Thanks Chris

I've been down that route... Here is what you need to do. Copy *.sys - \i386\system32\drivers Copy *.dll - \i386\system32 Copy *.exe - \i386\system32 Copy *.din - \i386\system32 Copy *.inf - \i386\inf Should work then.