search cancel

DS7.5 Bootwiz / Preboot Problems. Bootwiz may not run after selecting to Build or rebuild, Packages may be missing, etc.


Article ID: 158501


Updated On:


Deployment Solution


If you try to build a preboot environment, or rebuild one if you've performed an upgrade, Bootwiz never starts.  Even if you run the Delta Update manually, and update the configuation on the site server (package server in this case), BootWiz doesn't start (this is actually what used to work in DS 7.1).

Some of the symptoms may include:

  • Bootwiz never starts (as seen in Task Manager) on the SMP or an NBS Site Server
  • Bootwiz is not installed on an NBS Site Server
  • Bootwiz package is corrupt - Bootwiz will not run manually OR does not show proper OS files
  • Bootwiz package in the console shows an invalid package location.


There are multiple possible issues, including:


Misunderstanding - it's actually working, just really slow.

First, this is actually a misunderstanding.  BootWiz WILL actually start, but it may take a significant period of time.  On the SMP you should see near immediate results, but on Site Servers, especially remote ones, the delay could be significant!


BootWiz is now located in a package in DS 7.5, unlike the default installation in DS 7.1.  What this means, is that the package must be downloaded before it can be executed.  On site servers this is particularly noticeable though because of bandwidth constraints, site constraints (e.g. constrained package servers) etc.  The delay can be very significant.  Additionally, the trigger for the download (or update, e.g. if new drivers were added) is when the task runs, not like a package server which is updated when the package gets a new version.  This introduces a potential "new" delay that can be noticeable.

As a general rule, the delay should be seen only the first time BootWiz runs, or when the package has been updated with new drivers.  New drivers though should pose a very short delay as we only update the files that are missing.

Obviously, this issue will be seen every time a new package server is added.


Agent Plugin / Timing / Installation Issues

Another version of this problem comes essentially from being in a hurry.  When a Site Server is installed, only the agent is installed.  We may immediately go out and attempt to make it an NBS server, before some of the other agent plugins (e.g. Task is the most important of these) are installed.  If we do this, potentially, the policy to install NBS may get there before a number of other requisite policies and fail to install correctly.  At least one known issue is logged that Task has to be installed first, as well as another plugin.  It may be best to wait for a day before making a new site server an NBS server.


Missing files or Corrupt Installation of BDC

We've seen some instances where the BDC itself is broken, either because it's missing files or something else is wrong.


BDC on a Site Server is executed under the agent.  Assuming all default locations, on an NS, this will be from the following:

C:\Program Files\Altiris\Altiris Agent\Agents\Deployment\SBS\Bootwiz\{LONG_GUID_HERE.EN_US}\cache\bootwiz

In that folder, there should be a BootWiz.EXE and a BootWiz.TXT file.  The latter is a log file, and often BootWiz is actually running but failing.  If the folder is not there, obviously it will not run.  This may mean it's the other version of the problem.  If it is present though, look for the Bootwiz.txt file, open it, and read it.  Each "run" of Bootwiz is clearly diliminated.  Looking at the last or nearly the last "run" (start from the end) may tell you something.  Look for "invalid OS Type" or something of that effect.  If you find it, you're looking at a broken build.

Additionally, in the 'long-guid-here' folder, there should be 3 XML files: Snapshot, Snapdata, and Log.  The two "snap" files are updated, at least, every time you update the BDC, OR every time you click "update Distribution points" in the console on the BDC package.

If the files or folders listed above are simply missing, browse to the package "source" location to see where the problem "begins".  Assuming all defalt locations, on the SMP, look for:

Program Files\Altiris\Deployment\BDC\bootwiz

Launch Bootwiz.exe from here, cancel the create new config option, and then in the Menu, select Tools | Install Preboot Operating Systems.  The screen that pops up will have 4 preboot OS's and "should" have 3 of them selected including two from WinPE.  If 1,3, and 4 are not selected - do not have a check mark by them - then you're broken.

Finally, check the following location for 2 "shortcut" looking folders (actually, they're symbolic links and will have the exact same data as in the above location):

Program Files\Altiris\Notification Server\NSCap\Bin\Deployment

Check for the BDC "shortcut" / Link folder.  If missing, this is another clear indication of corruption.


Fixing Things

If the data on the SMP looks fine, but the data under the Agent is not, you may need to simply "wait" for things to catch up.  Check for all the appropriate sub-agents (e.g. DS Package Handler on package servers) and ensure that package replication is working, the package servers are updating, and that the agents are checking in.  Remember, it can take time.  And remember to actually trigger a build of the environment after making any changes you may need.  If the agent packages were not installed and now are, for instance, you'll have to now re-build the automation environment, which will create the task that will request the download of the BootWiz package.  Without asking for that to be built, you may wait forever...


If you think there's corruption, we have some suggestions that may resolve things.  Missing files or links or missing "anything" really can indicate corruption, and the following whould be followed.  Remember though to separate what is under the AGENT with what is under altiris\Deployment and/or altiris\Notification Server.  The latter two are server-side issues which we'll help fix with the steps below.  The fomer folder / the agent folder / even on the SMP, is a completely different set of processes.

  1. Using the SIM, repair DS. This is to ensure that nothing in the file system is missing from the SMP. For instance, we have seen BDC folders with only a partial installation. The \program files\altiris\deployment\BDC folder should have well in excess of 1000 files. If not, you MAY need to copy down a version of that folder from another working system (e.g. from Support or a lab server)
    NOTE: Running a repair WILL break the DS solution. If you do not then follow-up with the next step, you can expect things to fail. For instance, it is well known that the symbolic links under NSCap will be removed for BDC and DA.
  2. Reconfigure DS using AEXCONFIG by using the bat file 'dsconfiguration.bat' attached to this KB on the NS. At this point, you should confirm that the BDC package in the console looks healthy. Updating distribution points on that package will ensure the package servers get a current copy of that package.
  3. Check to make sure all files and folders were put in place correctly through the repair and reconfigure. Locations and things you need to check:
    • Both Pectagent.ini files have complete information (if they have @SMPPORT or @SMPPROTOCOL as the values, they need to be replaced with correct port and protocol, default 80 and http, respectively. They do however need to reflect what you are using in your environment). Located in:
      C:\Program Files\Altiris\Deployment\BDC\bootwiz\oem\DS\winpe\x86\Base\Program Files\Symantec\Deployment
      C:\Program Files\Altiris\Deployment\BDC\bootwiz\oem\DS\winpe\x64\Base\Program Files\Symantec\Deployment

    • Check for MSI.DLL and Shutdown.exe in the following locations (if not present, they are attached to this article):
      C:\Program Files\Altiris\Deployment\BDC\bootwiz\oem\DS\winpe\x86\Base\Windows\System32
      C:\Program Files\Altiris\Deployment\BDC\bootwiz\oem\DS\winpe\x64\Base\Windows\System32

    • Ensure Symbolic Links were created for the BDC and DriversDB folders in the following folder:
      C:\Program Files\Altiris\Notification Server\NSCap\bin\Deployment
  4. Wait. It takes a bit for services and policies to get all caught up with themselves. You may need to wait overnight, but you might be able to hurry things along by:
    1. Running a complete collection update
    2. Running a package refresh
    3. Ensuring that the SMP and Site Servers report up inventory
    4. Enabling the Site Service policies and subagents, and ensuring that site servers get them, AND send up basic inventory.
  5. Ensure you have at least one configured NBS server in Site Server settings. If not, BootWiz will run, but obviously never build anything for PXE. Ensure that it is running, the services installed and "still running) before moving on.
  6. Build or Rebuild a Preboot configuration. This is what actually triggers the download of BootWiz to an NBS server. Whether on the SMP or a site server, this will take time. It has to first download BootWiz and the Imaging tools to the Agent location (not the Package Server location), and once complete, it will THEN run.
    1. If after about 15 minutes, BootWiz never launched on the target NBS server, check the Altiris Agent \ Deployment \ logs folder for the DSTasks.TXT file. This is a log that should show what happened when you attempted to rebuild. It can be rather cryptic, so Support may need to look at that for you. This is one place we are seeing a known issue that we have not resolved. You can also check to see if there is a Deployment \ SBS \ BootWiz \ ... folder structure there. In the Bootwiz \ GUID folder, there should be a Snapshot.XML, Snapdata.XML and log.xml. These SHOULD be updated to the time/date stamp of today/now/when you ran.
    2. If you find that the BootWiz package IS present, that BootWiz when launched from the Agent folders works and shows the preboot environments, and that the NBS site server reports in the console as active, and BootWiz STILL will not run, check HOWTO93837 for a way to manually run BootWiz, but you should still call this in to support.

Any remaining errors you are runnning into after this should be reported to Support.


Additional "possible" tips that really should be avoided:

In an Emergency, the following steps MAY be useful, but should be generally avoided (that is, try this only after all else has failed):

You may be able to simply run a repair on the MSI for DS 7.5 from the Symantec Installation Manager\Installs folder. This is done by runing the symantec_deploymentsolution_7_5_x64.MSI file, and you should run this from a "Run" or command line with skipaim=1 directly following the name of the MSI.

Remember to run the configuration file again (step 2 above) if you do this.

IF the Symbolic links are still missing after the reconfigure, you can essentially force in the links by doing the following from command-line:

  • Connect directly to the Notification Server console session or remotely logged on.
  • Open a command prompt. Doing so with administrative rights may be nessessary, but you should be logged on with those rights anyway.
  • Browse to \Program Files\Altiris\Notification Server\NSCap\Bin\Deployment
  • type in the following 2 commands to create the symbolic links (source paths may need to be adjusted depending your product installation paths. These instructions assume the default installation of C:):
    mklink /d /j BDC "c:\Program Files\Altiris\Deployment\BDC"
    mklink /d /j DriversDB "c:\Program Files\Altiris\Deployment\DriversDB"
  • This should then create the two folders. You can verifty they work by browsing in the console to those packages and seeing if instead of showing an invalid location, they give you the size.





Attachments get_app
DSConfiguration.bat get_app