Video Screencast Help

New computer won't boot to PXE (2nd time)

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

After a new computer boots to PXE and correctly displays the initial deployment menu it won't boot to PXE again which is how I understand it should work..

However, the issue is if a known computer is deleted, I would expect it to be able to boot to PXE right away.. Is this how it should work? After it boots to PXE once and gets created as minint*****, I delete it and try to boot again which doesn't work.

Any ideas? I'd like to have our process be to delete known computers when reimaging so they are removed from any filters they were in before.


Comments 13 CommentsJump to latest comment

Gibson99's picture

the way i remember it, each pxe server (site server) keeps track of which machines it has sent the initial deploy stuff to, which to me is a waste of time/energy.  there's an ini or txt file in the site server's pxe directory where you can purge the name(s) you want to from it.  the trick is, you can't just purge the entire file or everyone will suddenly get initial deploy on their next reboot.  i'd give you the exact path, but we don't have any 7.1 pxe servers anymore.  this was just one of the many factors that made us stay on DS 6.9.

i really think symantec made this one unnecessarily complicated in an effort to reduce load/traffic on the main NS (SMP) server.  sure, i suppose it probably helps minimize wan traffic, and could maybe help site servers work independantly in case they lose communication with the NS, but it's not worth the tradeoff in our environment.

If a Connect post helped you out, be sure to click "Mark As Solution" or the "Thumbs Up" button to let other users know about it.

Gibson99's picture

forgot an important detail!

once you purge what you want from that file, you then have to restart the pxe services on that site server, since it caches those files in memory when pxe starts up.  these services are always right at the top of your list, since they start with _ (underscore).  

If a Connect post helped you out, be sure to click "Mark As Solution" or the "Thumbs Up" button to let other users know about it.

Dustin Perkins's picture

Interesting.. However, we need an imaging process that will be simple and all of our technicians will have access to perform... In DS 6 we would create a new computer and giving it the name and MAC so that we can schedule an imaging job and it will grab it on boot..

What would be the closest match using 7.1?


Gibson99's picture

I don't think that functionality exists in 7.1 yet.  and since we needed this NOW (well, a year ago actually) rather than later, we went with DS 6.9.  

If a Connect post helped you out, be sure to click "Mark As Solution" or the "Thumbs Up" button to let other users know about it.

Transporter's picture


I have exactly the same issue.

The server does a PXE boot, The servers becomes visible in the Altiris console onder new computers.

I attach a job on the computer, the server reboots and fails to boot in PXE again, (The NIC gets an IP address again from the DHCP server) it gives time-outs.

I put the logfiles on full logging

In the PxeLog_Mtftp.Txt logfile I see stuff like this (Amoughst other errors, but too much to copy paste in here) Despite the error log I have no clue why.


    (3784):      Search socket does not match: No processing done
D [12:59:11.839 06/05] (3784): CheckForRetryTimeout: Socket: search: f0  Found: f4


D [12:58:15.943 06/05] (3784): HandleTFTP: action: next block  IPAddr=
  (3784)HandleTFTP: P_ACK for blk: 27 want blk: 28
  (3784)SendUCast: blk = 28  IPAddr:
  (3784)Cache 0 Data Returned (refread:1)
  (3784)MySendTo completed: len = 516


D [12:58:15.912 06/05] (3784): RemoveClient: client found - FHd: 1  IPAddr=
D [12:58:15.912 06/05] (3784): RemoveClient: client found do reset - FHd: 1  IPAddr=
D [12:58:15.912 06/05] (3784): RESET Transfer Table Slot: Previous Information
  (3784)     File Name: c:\Altiris\Deployment Server\PXE\images\Bstrap\X86PC\BStrap.0
  (3784)       File Hd: 1
  (3784)        IPAddr:
  (3784)          Port: 1758
  (3784)          Type: 1
  (3784)    Last Block: 1
  (3784)          Wrap: ffffffff
  (3784)          Done: no
  (3784)     File Size: 23285
  (3784)   UCast Sends: 0
  (3784)  Segment Size: 768
  (3784)CloseFile: reference count = 0
D [12:58:15.912 06/05] (3784): CreateUCast: Ucast client:
D [12:58:15.912 06/05] (3784): Enter: GetSlot(...)  Transfer Table Size: 200
  (3784)Transfer Table: available slot = 1
  (3784)CreateUCast: File Name: Bstrap\X86PC\BStrap.0
  (3784)RestrictFilename: File Search:c:\Altiris\Deployment Server\PXE\images\Bstrap\X86PC\BStrap.0
  (3784)RestrictFilename: Search Results: true [1]
  (3784)RestrictFilename: Path found: c:\Altiris\Deployment Server\PXE\images\Bstrap\X86PC\BStrap.0
  (3784)RestrictFilename: Match Root: c:\Altiris\Deployment Server\PXE\images
  (3784)FM_Open: Max Slots:128  Used Slots:0


If I delete the computer object from "New computers" I can boot PXE once again correctly untill I attach the Job and we're back from the start.

All info is apriciated.

donald_noah's picture

As Gibson99 said, you would need to delete files out of the SBSStore. You can delete all files that are <guid>.sbs. Leave any of them that have <string>, <string>-client.sps, and If you delete these 3 files, you will have to recreate the preboot environment from the console.

Unfortunately, the <guid>.sbs files offer no clue as to which worstation they belong to. Maybe a Symantec Engineer could chime in and offer a way to identify.

Otherwise, deleting all the <guid>.sbs files will result in every workstation that communicates with that Deployment server to see the the "press F8" option during boot for 3 seconds. I believe this is changing in DS 7.5. They will only see this once, and on next reboot, the SBS record would have already been created and therefore they will not see it again.

Donald Noah, Systems Engineer
Intuitive Technology Group -- Symantec Platinum Partner

Dustin Perkins's picture

Looks like I found a work-around that might be an option for you too:

After deleting the computer, I import it in as a predefined system. This allows the system to boot to WinPE using PXE once without having to restart any services, recreate preboot environments, or delete any files...

Even though this is not as easy as DS 6.9, I feel this will be an easier/safer process to have our guys follow.. At least until 7.5 is released which I heard will bring the 6.9 imaging abilities back...

Thank you all, if you have any other suggestions, please share!

Dustin Perkins's picture

I guess I spoke too soon.. It now won't stop booting into PXE even after the system is no longer showing up in the predefined computer list.. Is deleting these files and recreating preboot configurations really the only way to have this function as the guide says it will?

Thomas Baird's picture

Restart the PXE Server service on the site server.  Period.  This enables the F8 option for all systems that PXE server responds to.  However, it takes about 1 min for the PXE Server service to actually start and be bound on all ports.

In DS 7.5, you don't have to do anything.  VAST improvements have been made that you'll see... when it's available.

If you want to get Initial Deployment to fire as well, and the PXE response associated, then you also have to delete the computer from the console, but that makes sense, because once it has booted to WinPE, it's no longer an "unknown" computer.  Just remember to also restart the service for the PXE response above.

As for those who are trying to remember what is going on.  First, the Dataflow and Architecture document spells this process out in detail.  Maybe too much, but it's all there.

The short answer though is that the PXE has an internal table (in 7.1, not in 7.5) that documents what each computer is supposed to boot to.  Once a "boot to" task is received for a system, the F8 option for that system is gone, until the next time the service starts.

One final note.  Please do NOT confuse PXE with WinPE/Preboot environment.  The twain never really meet and are NOT the same.  A PXE response to the computer has absolutely nothing at ALL to do with the Initial Deployment menu showing up in WinPE.

Thomas Baird
Enthusiast for making things better!

BugTastic's picture

Would be interested in these improvements...any other info you could share ;-)


Thomas Baird's picture

Not 100%, but write me if you can't find it.  I'll ping the PM to be sure, but not until next week.

I know one of the Vision slide decks was all about what's new in DS 7.5 though.

Thomas Baird
Enthusiast for making things better!

Transporter's picture

I found the (my) issue.

The Job had a script configured to run as Linux, But due some other issues I removed the Linux PXE boot images.

So I booted PXE in WinPE, next script was Linux so it rebooted and wanted to boot linux, but since they were no longer available it looped.

Next step is trying to recover my Linux PXE images.:)

Dustin Perkins's picture

After restarting the services (in the correct order) all has been working fine. The NS has even rebooted since then and we still imaged 30 systems with no issues.