Deployment Solution

OK I finally got my own VLAN to be able to safely test PXE on my site server without breaking anything on the regular network.  My machines on the new vlan can get IP addresses, and can connect to other machines on the regular vlan as well as the internet.  When i try to pxe boot a machine on the new vlan, it doesn't try to boot from the DS6.8 server, and machines on the regular vlan DO continue to boot from the ds6.8 server.  so it all seems well and good.

the network guys told me what static IP and such to set my site server to, which i did.  started SBS services in the right order using a batch file (interface, server, signal, mtftp), and i didn't notice it right away, but interface would start, then crash about 3-4 seconds later.  event log was pretty useless:

Event Type:    Error
Event Source:    Service Control Manager
Event Category:    None
Event ID:    7034
Date:        1/28/2011
Time:        2:13:22 PM
User:        N/A
Computer:    ALTSS-TEST
Description:
The _Symantec_netBoot_Interface service terminated unexpectedly.  It has done this 1 time(s).

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

i started poking around the SBS dir and found that something keeps setting the IPs in the initialPXEConfigPath.sbs and .txt (and several other .sbs files) to the machine's old ip address. 

where can i go to force this to use the new ip?  i tried stopping the sbs services, changing the IP in both the .sbs and .txt files then restarting, but it didn't help - something's updating the files programatically, and i can't find where it's coming from.

I really don't want to have to uninstall the site server bits and reload them (and thus wait for package replication and such), but i'm starting to think that's what i'm gonna have to do. please prove me wrong!  :)

If I understand correctly, you tried the steps in this article:

http://www.symantec.com/business/support/index?page=content&id=TECH127349

And the issue was not resolved?  If so, have you tried these additional steps?

http://www.symantec.com/business/support/index?page=content&id=TECH138155

Does this resolve the issue related to the IP address change?

that's exactly what i did, though i did it without those articles.  something is changing the txt file after i do - i can see the file time stamp has changed. 

when changing the txt file didn't cure it, i started looking deeper, into the .sbs files.  changing those didn't help either.  whatever it is changed those back, too.

If your settings are correct, based on both KBs and both files, I'd suggest opening a case with support.

yesterday on a whim i decided to try changing the txt file again.  i made sure the services were all stopped (they were, and had been stopped over the weekend).  I changed the txt, saved it, then started the services a few minutes later.  i waited a bit on purpose so that i could see a new timestamp on the file if it happened. It didn't change the txt file. and the services stayed running.  they're still running this morning, too.  not sure what the deal is/was...

now, i'm getting PXE-E32: tftp timeout on the pxe clients. i'm not sure if this is an issue with the network configuration or something in the mtftp server config, but i figured i would stop the services, turn on mtftp logging in the text file, then restart the services.  and of course - interface crashed again.  i also noticed a few new .sbs files being created in the task handler\sbs dir - initialpxeconfigpath.sbs, 1694085149-client.sbs, and 739024490-image.sbs

i walked away for a few minutes, and saw a few newer files... including initialPXEConfigPath.txt... which had yet again reverted to the old IP address!  Whiskey Tango Foxtrot?!?!

OK, deep breaths... :-)

now that I have everything written down here, I'm gonna go ahead and call support.  Thanks for your suggestions, mclemson.

Hopefully support can put the nail in the coffin on this one for you.

well, support found the old IP address lurking in the database. for the curious, it was in the "sbs_serverlist" table.  there's very little stuff in that table at all so it was really obvious what we had to change.  for anyone else seeing this problem  - if you have more than one site server (i don't... yet)  you'll need to find your site server's OLD ip address in this table and change it to the new one.  then make sure it's set correctly in the .txt file, delete any stray .sbs files in the root SBS folder as well as the delta file (.xdf or something).  then start the services.  these files will get recreated automatically.

so far, the services are behaving themselves, and nothing is changing the .txt file back to the old IP.  the txt file is SUPPOSED to be regenerated on a regular basis, and it has to do with how often your updates are configured for in the NS.  since i have mine set to very short intervals on my test server (5-10 mins in several locations) this happens quickly.  i only put the intervals that short because it's a very low volume test environment - i don't expect to have more than 15 clients on it, ever, and i don't want to have to constantly open the client on each end point to tell it to update configuration every time i change some policy or whatever. 

sooo... now i just need to pxe boot a machine and make sure i'm not getting the pxe-e32 anymore.  unfortunately with this weather, i won't be doing that any time soon.  since we don't have vpro working yet, i can't do it from home.  that will be pretty cool when we do!

ahh, the blessing/curse of being able to work from home...