Deployment Solution

After our DS is rebooted, and the new symantec netboot services are started again, the only option shown on the pxe boot menu is Next Device.  I've seen this behavior where my boot images will show up again in around an hour.

Also, when using the "Recreate Preboot Environment" option in preboot configurations, it takes too long to do it's deed.  The boot images aren't being rebuild until BootWiz.exe shows up in the task manager, per support.  After clicking recreate, I've seen it take 30minutes to 1 hour for the BootWiz process to show it's face.

Any help is greatly appreciated.

Your thread looked lonely, I imagine not many of the experts here can totally help with DS 7.1 issues. Although i dont get the same problem I lost the PXE boot menu completely at some point during our 7.1 migration. Also the way "known" PC's and "unknown" PC's are dealt with has gotten muddled. Restart the PXE services, and a known PC will be dealth with by getting the WinPE environment sent and then just waiting at automation partition for infinity...which is particularly dangerous!

I believe there might be some tweaks and hacks Symantec are holding onto regarding the way Site servers/PXE servers talk to the NS and to get hold of these your best bet might be to log an official call.

Concerning your main question; this is the way the DS behaves and, I've been told by support, there is no 'fix' yet.  There is a work around though.  You have to restart all the '_Symantec_netboot_'... services.  Here is the Script I use:

------------------------------------------------------------------------------------

------------------------------------------------------------------------------------

'Created by: Xalam

Dim objnetBootInterfaceSVC, objnetBootServerSVC, obnetBootNSiSignalSVC, objnetBootMtftpSVC, strComputer, WshShell, objWMI, AutoSvc1, AutoSVC2, AutoSVC3, AutoSVC4, strStartupType, arrStringValues1, arrStringValues2, arrStringValues3, oReg, selector

Const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."
Set objWMI = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set objnetBootInterfaceSVC = objWMI.Get("Win32_Service.Name='_Symantec_netBoot_Interface'")
Set objnetBootServerSVC = objWMI.Get("Win32_Service.Name='_Symantec_netBoot_Server'")
Set obnetBootNSiSignalSVC = objWMI.Get("Win32_Service.Name='_Symantec_netBoot_NSiSignal'")
Set objnetBootMtftpSVC = objWMI.Get("Win32_Service.Name='_Symantec_netBoot_Mtftp'")
Set WshShell = WScript.CreateObject("WScript.Shell" )
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")


' Run script based on user argument -- will not run without argument


If wscript.Arguments.Count = 0 Then
    
    MsgBox "ARGUMENT NOT GIVEN",16,"ERROR"
    call Help()
    call CleanEnv()
    Wscript.quit(3)


Else

    If wscript.Arguments.Count > 1 Then

    MsgBox "TOO MANY ARGUMENTS",16,"ERROR"
    call Help()
    Call CleanEnv()
    Wscript.quit(3)

    End If


    selector = wscript.Arguments(0)

    Select Case Selector
    
        Case "/all"
            Call StopServices()
            Call EnableAutoStart()
            Call StartServices()
            Call CleanEnv()
            Wscript.quit(0)

        Case "/stop"
            Call StopServices()
            Call CleanEnv()
            Wscript.quit(0)

        Case "/start"
            Call StartServices()
            Call CleanEnv()
            Wscript.quit(0)

        Case "/restart"
            Call StopServices()
            Call StartServices()
            Call CleanEnv()
            Wscript.quit(0)

        Case "/enableauto"
            Call EnableAutoStart()
            Call CleanEnv()
            Wscript.quit(0)

        Case Else

            If wscript.Arguments.Count > 0 Then


                MsgBox "INVALID ARGUMENT",16,"ERROR"
                call Help()
                Call CleanEnv()
                Wscript.quit(3)
    
            End If

    End Select


End If

'---------------------------------------------------------------------
' EnableAutoStart() Sub

Sub EnableAutoStart()
    strStartupType = "Automatic"
    AutoSVC1 = objnetBootMtftpSVC.Change(,,,,strStartupType)
    arrStringValues1 = Array("Tcpip", "_Symantec_netBoot_Server")
    oReg.SetMultiStringValue HKEY_LOCAL_MACHINE, "SYSTEM\CurrentControlSet\Services\_Symantec_netBoot_Mtftp\", "DependOnService",arrStringValues1
    
    AutoSVC2 = obnetBootNSiSignalSVC.Change(,,,,strStartupType)
    arrStringValues2 = Array("Tcpip", "_Symantec_netBoot_Server")
    oReg.SetMultiStringValue HKEY_LOCAL_MACHINE, "SYSTEM\CurrentControlSet\Services\_Symantec_netBoot_NSiSignal\", "DependOnService",arrStringValues2

    AutoSVC3 = objnetBootServerSVC.Change(,,,,strStartupType)
    arrStringValues3 = Array("Tcpip", "_Symantec_netBoot_Interface")
    oReg.SetMultiStringValue HKEY_LOCAL_MACHINE, "SYSTEM\CurrentControlSet\Services\_Symantec_netBoot_Server\", "DependOnService", arrStringValues3

    AutoSVC4 = objnetBootInterfaceSVC.Change(,,,,strStartupType)
End Sub


'--------------------------------------------------------------------------------
' StartServices() Sub

Sub StartServices()
    objnetBootInterfaceSVC.StartService()
    objnetBootServerSVC.StartService()
    obnetBootNSiSignalSVC.StartService()
    objnetBootMtftpSVC.StartService()
End Sub


'-------------------------------------------------------------------------
' StopServices() Sub

Sub StopServices()
    objnetBootMtftpSVC.StopService()
    obnetBootNSiSignalSVC.StopService()
    objnetBootServerSVC.StopService()
    objnetBootInterfaceSVC.StopService()
End Sub


' HELP() Sub - Incase Invalid program call

Sub Help()
    wscript.echo "PXE_SVC.vbs Help" & Chr(13) & Chr(13) & "USAGE: PXE_SVC.vbs [Argument] " & Chr(13) & Chr(13) &  " Valid arguments: /stop - Stops all PXE services;  /start - Starts all PXE services; /enableauto - Implements PXE service dependencies and sets services to Automatic startup; /all - performs all operations required to install KB51553 provided the installation file is in the same directory as this script, set service dependencies, and start the PXE services"
End Sub



' CleanEnv() Sub - Zero all constants

Sub CleanEnv()
    Set objnetBootInterfaceSVC = NOTHING
    Set objnetBootServerSVC = NOTHING
    Set obnetBootNSiSignalSVC = NOTHING
    Set objnetBootMtftpSVC = NOTHING
    Set strComputer = NOTHING
    Set WshShell = NOTHING
    Set objWMI = NOTHING
    Set AutoSvc1 = NOTHING
    Set AutoSVC2 = NOTHING
    Set AutoSVC3 = NOTHING
    Set AutoSVC4 = NOTHING
    Set strStartupType = NOTHING
    Set arrStringValues1 = NOTHING
    Set arrStringValues2 = NOTHING
    Set arrStringValues3 = NOTHING
    Set oReg = NOTHING
    Set selector = NOTHING
End Sub
--------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------

As noted in the script, the services are:

- '_Symantec_netBoot_Interface'

- '_Symantec_netBoot_Server'

- '_Symantec_netBoot_NSiSignal'

- '_Symantec_netBoot_Mtftp'

 

Also, a hotfix may need to be installed if you are having trouble with the services

'altiris_deploymentsolutiontaskserverhandler_7_1_kb51553<qtlend></qtlend><qtlend></qtlend>_hf1_x86.msi'

 

Also, concerning your second question, just do an update to the Altiris agent on the console itself.  This will start the 'BootWiz' process earlier, as it depends on the agent update interval.

<qtlbar dir="ltr" id="qtlbar" style="display: inline; text-align: left; line-height: 100%; padding: 0pt; background-color: rgb(236, 236, 236); -moz-border-radius: 3px 3px 3px 3px; cursor: pointer; z-index: 999; left: 387px; top: 2819px;"></qtlbar>

We understand now MOST of what you're seeing, but not all.

First Bootwiz:

Preboot environments are sent down via policy.  Thus, there are two things that have to happen before BootWiz will run on the site server (including the NS): 1) Delta resource update has to run so the SS is in the appropriate filters to receive the policy update, 2) the client has to check in to get the policy.

Now, most people have Delta set to 30 minutes or an hour these days.  The default is 5 minutes.  Policy updates default to 1 hour, but most people stretch that out as well.  Depending on how you stretch these out, there will be a significant delay in the running of BootWiz.  If you're in a hurry, manually run the Delta, then have the system check in, and you'll see Boot Wiz running right-quick.

TIP:

If you don't combine your PXE configurations (i.e. don't put x64 and x86 into the same configuration) you'll gain greater control over the client boot (we recommend x86 wherever possible) and shorter BootWiz run-times.  Anyone who has watched knows that BootWiz takes about 15-20 min to run... per environment, so if you have X86, X64, and Automation Folders in the same build - an hour later it's done.

Empty PXE Menu:

I'll explain, but there may be ... something else going on after this explanation, but you can at least troubleshoot it.

In both DS 6.x and 7.x, the Server service contains the PXE menus.  These are not files on the drive that you can see and edit, per se.  When you restart the Server service (4th on the list in DS 7) it's empty and knows nothing.  It then queries the NS to find out what computers you have and what menus you have.  Any updates are sent via Task.

Sort of.

What's really happening goes a little like this (we're making a White Paper on this, but it's not done and there's still more research needed):

1)  Make sure your services are starting in the right order.  From top to bottom, it's 1, 4, 3, 2.  Interface needs to be first.  This is in control of the SBS files and the SBSStore folder.  Server needs to be next so that data can be read into it.  Signal needs to be next, and there's something cool and simple here you'll have fun watching.  TFTP doesn't matter what order, so we put it last.  We have a script that helps you build these dependencies.

2)  Look at the Signal.ini file.  It launches an exe.  For testing, try turning all your SBS services off and just manually run the exe.  It will create 3 files in the SBS folder within about a minute or less.  Look at each of these.  Once read, the information in them is handed to the Server service and the files are put in the SBSStore folder (which is really more of a log folder and can be purged any time if needed).  Notice that one of these is called Images.  Voila - that's what's being read into SBS to tell'm what menu it needs to display.

It's POSSIBLE that something is messing this step up, and that only after an update of some kind does your Server service actually get the menu.

Test this theory as follows - it might be interesting whatever the case.

1. clear the SBS store folder.
2. restart the SBS services.
3. wait 5 minutes to be sure any startup process is done and observe the SBSStore folder contents.
4. Recreate some configuration or something - see if a file is added to the SBSStore folder.  If so, look at it (notepad).
5. Send a job to reboot a computer to automation and do the same thing.

It's possible some step here is updating the Server service.  Sorry, we're still working out some of the kinks in the process.

 

 

I hope this gives you enough to chase this down.  For the rest of the readers - yes, the white-paper is coming, and I'll be posting it here.  A week or two maybe?  Depends on work load.  Oh, and we have to test the new MR2 now to see if anything changed...  <sigh>

I think it is working as designed.  I guess u want to press F8 at the PXE menu and select your preboot right?   why not send a "reboot to"specific PXE image task/job and don't worry about the menu?

Nelo

The 'F8' option will disappear, however, if the server is restarted or if the PXE services are restarted, and will not appear again until the Preboot environment is recreated.  --A fluke is suppose--

Are you starting the SBS services in the correct order?  They should be started 1,4,3,2 if you order them from top to bottom, or, Interface, Server, Signal, MTFTP.  This is optimal to making sure they pick up their settings from the NS.

Normally, the F8 menu would be present after about 1 minute if you do this correctly.

We have a KB and script that will set the services to auto-start and set up dependancies.  I'll post that up shortly as well.

OK - I posted the tasks mentioned in the previous post.  Find them here:

http://www.symantec.com/connect/downloads/ds-support-tools-71013-task-pack

One of these includes a task to set up the dependancies on any SBS Site Server, including the NS.

Apologies for trying to ninja this post.

images.sbs

Status=UpdateImage
Image=BStrap
Arch=x86
OptID=99
Image=BStrap
Arch=x64
OptID=99
Image=NHSWinPE2
Arch=x86
OptID=
 

Initial PXE configpath

Status=Configuration
Server_Log_Enabled=False
Mtftp_Log_Enabled=False
Helper_Log_Enabled=False
iFace_NS_Log_Enabled=False
ParsePxe_Log_Enabled=False
PxeOpts_Log_Enabled=False
FilterIP_Log_Enabled=False
FilterMAC_Log_Enabled=False
FilterUUID_Log_Enabled=False
Server_Ukn_Enabled=True
Server_Listeners="10.8.120.12"
Server_EnabledParsers="SbsParsePxe"
Mtftp_MTUSize=1456
Mtftp_Root_Folder=D:\Altiris\Altiris Agent\Agents\Deployment\Task Handler\SBS\Images
Mtftp_Listeners="10.8.120.12"
Mtftp_MaxTransfers=200
Server_Ukn_Image=NHSWinPE2
Server_Ukn_Arch=x86
 

NHSWinPE2 is the name of our WinPE boot image.

I changed NHSWinPE to be Bstrap and got an e77 once but i cant seem to do that anymore i forgot the order i did things in.

I dont have permissions to get into your link above

F8 menu simply being bypassed. Unfortunately i need it to be there and time out to boot to next device or lots of badly configured PC's will boot to WinPE and call my Helpdesk. On an estate of 11,000 PC's i dont really want to do that.

Currently i have 6.9 running on the same server. 6.9 does what i want it to do...it boots to the F8 menu where a technician can force it to go to an imaging PXE boot menu. Unattended it just boots to Windows even with PXE active. Which works for us.

Any ideas?

Hi

O paste some paroblem with PXE

Dont rename any folder and image the proces must end self.

You dont push any operation.

Please check job on NS or PXE server SBSupdate is hi end ???

0. create new PXE enviropment in NS delete old from list in PXE configuration.

1. stop all PXE service

2. clear sbs store folder

3. start services in order interface - server - signer - MTF

4. wait to create new folder with new env and del old . ( sbs do this )

 

SBS must comit his work this may take some time .

Michal

You can't have 2 PXE servers on the same server.  Not shouldn't - can't.  There's simply no possible way to do it.  Either one will hear the request, or the other.  They can not be made to share.  If PXE is working for DS 6.9 on a box, you shouldn't have DS 7.1 SBS services on the same box.  The services COULD be on the same box, so long as one or the other is disabled.

Second, make sure those images built correctly.  There is an images store under SBS that will store the builds of your images - much the same as it did for DS 6.9.  These are the WinPE images.

Third, check the IP addresses in there, and take a close look at the Signal.ini file.

Fourth, be sure about the SBS services.  The tasks I posted are now available - sorry about the delay.

Fifth, be sure the client?.sbs file is created prior to booting.  That one has the identities of your systems so SBS knows what to do with them.

 

Oh, and be aware that we don't have MAC filtering yet in DS 7.1.  If your systems aren't configured correctly to avoid a network boot and/or aren't known, then we need to be sure not to use initial deployment.

 

OH OH!  And MR2 is out with several fixes like for the issues we've been seeing here.

I'll check the other stuff but we asked about the double PXE and were told its fine as long as they are both not running, and ofc, we switch between the services otherwise that would be silly.

Both appear to work otherwise although if you can think of a reason related to the disappearance of the F8 menu after a while (and not returning but we did have it once) then please let me know :)

Given its not working then MR2 looks like a good plan, will come back and let you know.

It may sound silly, but uh - we see it.  :(  Sorry if I insulted your intelligence.  Trust me - we see it.  <sigh>

Seriously, I posed another question about the client list.  Did you see that file come through?

And, did you start the services in the correct order?  Usually, this is working.

Oh, and you said you have how many clients?  Based on the 10K I read there, you should have at least 2 or more site servers.  If you do, which site server is your client connecting to?  If not - get them.  Perhaps I misunderstand what we're seeing here, but I am a bit blind here.  LOL  There's only so much we can do over texting.

Anyway, generally speaking, if done right, we've seen pretty close to 100% success for tests like what you're doing.  You showed me that 2 of the files are coming down fine, probably kept back the 3rd because it has IP and Mac info.  Fine.  That suggests that Object Host is running, as is Signal.exe.  But it doesn't tell me when they were created, or if the Server Service was running at that time or not.  If not, perhaps it didn't get the update.

Well, look at MR2 and see if that helps a bit, but to move forward, we'll probably need more info.

No probs, ok will give a little more info. :)

11K clients but that server hosts about 1400. Newly went to NS7 but the DS7 wasnt working so we left it installed on the task server and the services off.

We swap services when we want to see how DS7 PXE is working. If its on too long a PC will reboot somewhere and end up looking at a WinPE command line :)

When we first installed DS7 we had the F8 menu. I asked the contractor to configure DS so F8 menu was there to default and boot to hard drive if there was no interaction. Then we want 'known PC's' to respond to any jobs and if no jobs then boot normally. Unknown PC's we would like to boot to a menu for imaging.

During tests the F8 menu came up a few times. Then it disappeared and now after PXE launches on DS7 it goes straight into launching our WinPE image.

For your questions:

Yes, started services in their particular order. Waited some time after

Also did the test by running the executeable and watched the 3 files be created. I showed only two of them because the other didnt seem to have any interesting information in it. They appeared in this order:InitialPXEconfigpath.sbs, 12345678910-image.sbs and 12345678910-client.sbs. Images and initialPXEconfig I listed the content in the file above. the third file, client has this entry:

12345678910-client.sbs

Status=UpdateComputerStatus
UUID={4C4C4544-004C-5610-8059-CAC04F4D344A}
MAC=00101866D10C
UUID={4C4C4544-004D-4210-8031-B7C04F35324A}
MAC=00137250132D
SBSIPList=10.8.120.12

Which is the server details.

InitialPXEconfigPath comes up 4 seconds after running, the other two, together after 22 seconds. All PXE services are running at the time.

If i clear the SBSstore folder and restart the services i watch the three new files being created. If i dont delete the folder and watch the services restart then i get new client and server files created with different prefixes.

I can delete or edit these files in the SBSstore and it makes no difference to the outcome, PC boots to PXE, after you see the MTFTP........dots going -> it then briefly flashes "Altiris pre-select automation processing" and goes into WinPE.

See, it looks like it has 2 PC's known, but that's all.  Interesting.

Not getting the F8 menu is what we sort of hope for if you have it responding to unknown computers.  It should be fast enough to not need F8 (and you'd have to jump quick to interrupt the process).  We are "supposed" to know how to treat the system, whether to boot to a known preboot, or to production, or to initial deployment, and not have to have you press F8 - thus hands free.

What if you tell it NOT to respond to unknown computers, does that give you your F8 back?  Please try this just to see if that's the difference, OK?

Yes F8 is back. It appears the problem isnt that we have lost the menu but that the PXE server is treating all the machines as unknown (well all bar 2).

I have no idea what the process is where the PXE server "get to know" the PC's. Is there any chance someone could help me troubleshoot this process?

How many of the systems that you are booting are actually managed computers?  That is, if in the NS Console you go to Manage | Computers, how many are listed in there, AND how many of them actually have the Altiris Agent on them?

In theory, any computer with the Altiris Agent that is reporting to that list should be known to the SBS server.  Any that are NOT on that list will be unknown, period.  There can be computers on that list that are not known as well if they came in through an AD import instead of basic inventory from the Altiris Agent.

There is however, one other possibility.  IF the computer is known to the NS, and IF the computer, in production is checking into a different site server than the one it PXE boots to, the PXE server may not know about it.

I'll explain, and this is something we're actually working on fixing.  I'm not sure if we got the fix into MR2 or if it'll be in MR3 or not - but I can find out.

Explanation:
Pretend you have the following configuration [NS = Notification Server, SS = Site Server, WS = Workstation]:

• NS and SS1 are in SiteA
• SS2 and SS3 are in SiteB
• WS1 is in SiteA and connects to SS1 for tasks.
• WS2 is in SiteB and connects to SS3 for tasks.
• SS1, SS2, SS3 are all Task Servers and PXE servers (per recommendations and requirements for full functionality of DS today)
• Single DHCP server services all WS/SS in all sites.

Now, let's just say that you use PXE Forced Mode - that is, you use DHCP to point any NIC trying to PXE boot to a single PXE server.  We'll pretend that is SS2 for this discussion.  Because of that, in theory, you can leave the PXE services off on SS1, SS3, and the NS.  Right?  The clients will never hit those PXE servers, so no need for active services.  NOTE: you still have to have the site components installed on those systems even if the pxe services are off, so the tasks will work correctly!!

Here's where the problem can arise.  The NS is smart enough to send to the PXE servers only those client's or WS information necessary for those pxe servers to process.  I don't remember exactly yet (white paper still in progress) but each pxe server either gets only the information for those clients connected to it for task, OR information for only those in it's full site.

Assuming the latter, SS1 and the NS would get a list of all computers in SiteA, and SS2, SS3 would get a list of computers in SiteB.  Are you seeing where this is going?

If a WS1 boots to PXE, DHCP routes them to the Site Server in SiteB, where the list of computers for SiteA was not sent.  That computer is treated like an unknown computer.  WS2 however boots to PXE, and is treated as "known".

 

Yeah, we've seen this before.  The current proposal is to simply send ALL computers to ALL PXE servers.  The concern was that if you have 200K systems, that's a lot of computers to keep in RAM for the PXE server service.  I believe though that after thorough calculations, this is deemed acceptable.

You'll have to see if that's what's happening to you.  Let me know if the description above was sufficient or if you need more information.

Thanks!!

Hi again, thanks for the help on this :)

NS7 is fully deployed on the estate, there are 5 site servers and they function correctly as task servers for software deployment. This particular task server is the only one with PXE 7 on it and the NS notes this is the only PXE server there is.

Therefore, yes, everything has a client and some 1400 should be pointing to the Site server in question as they are pointing to the same task server.

However by the end of today none of them are known to PXE.

I'm wondering if it has anything to do with the other task servers not having PXE on them? Maybe not but its the only thing different form a default installation, in that we put the new PXE on only one site server.

is there a manual way to forward this info to the PXE server? is it run as a policy somewhere or some internal task, or via the client? Anything i can look at?

I need to check and see if they have a point fix for this, but... Frankly, I think this is a pretty good point in which to call support.  You have all the evidence you need, and it would be useful for Support to look at the actual issue and perhaps get some data from your system to Dev, OR maybe get you a point-fix.  I don't think there is anything you can configure, and even if there is, this is something that should be documented.

I'll keep trying to look (I do have a job too...) but that's my recommendation at this point.  Your call of course.  :-)

many thanks for yours and everyone else's help :) It was useful anyway to understand the problem.

Updating this with a resolution.

The problem was caused by the installation being recent, the NS being on the same physical site as the site server the order of the installation of the site server and the way in which PXE mechanisms work.

The issue was that the PXE server was treating most of its clients as "Unknown" and performing the Initial Deployment task on most machines connecting.

The reason was that clients were reporting to the NS task server mostly since it was the first site server up and they didnt reset their task agents (being a fairly recent install). The NS passes the information to the PXE servers as to which computers are known or unknown. However this was short of the true amount because clients were reporting to two task servers. Thus some clients were unknown to PXE and performed initial deployment and others were known and treated normally - depending on the task server they were reporting to.

The fix is in two parts. For further details check http://www.symantec.com/business/support/index?page=content&id=TECH133468

This edits a stored procedure to either supply ALL the clients to the PXE servers (and potentially delay response to the client negatively, or supply it in chunks of sites)

The second part is to remove the "respond to unknown computers" option in PXE management on the NS. That step may depend if you need it in your environment, for us it was ok.

Thanks to Edmir in Symantec and Thomas above who helped us through this.