KNOWN ISSUE: DS7.1: Preboot Configuration policy is missing a Target even though all else is configured correctly
Last Updated August 16, 2011
Preboot Configuration(s) created in the NS console are never sent to the NS and/or Site Servers that SBS server(s) installed (PXE server).
There are several known causes for this that are being researched by Development:
Right-click to enable the policy may prevent the target from being created and/or linked to the policy.
The Target itself may get deleted or was never installed during the initial setup (usually the former)
A top-level policy in Hierarchy may replicate a missing link to the target.
Before applying the solution listed below verify that this is the issue being seen by following the steps listed below:
Check the filter. Check to see if the SBS (PXE) server is listed in the Computers with Deployment Site Server Component installed (x86) filter. From the Symantec Management Platform console select Manage | Filters then Software Filters \ Agent and Plugins \ Computers with Deployment Site Server Component installed (x86) . The SBS (PXE) server should be listed. If not, review TECH127397
Check the target. Use SQL to see if a target actually exists in the database by running the following against the Symantec_CMDB database:
select * from item where guid = 'd9533379-06ab-4b99-b164-e9b9ce7c127a'
If this returns a result, then there is another issue and we should review TECH127397.
If not, try the following SQL:
select * from itemdeleted where itemguid = 'd9533379-06ab-4b99-b164-e9b9ce7c127a'
Take note on if you get any result. You may need this if you have to call support.
Check the XML. Another check that is not definitive but can help point to a problem is to view the XML for the Preboot Configurations policy page. Using the left pane of the normal NS console (not the Deployment portal), find the policy, right-click, and select "View as XML." This will open up a page of XML, likely in a browser. Scroll to the bottom where you should see something like this: </security> <itemReferences /> <resourceTargets> <resourceTarget guid="d9533379-06ab-4b99-b164-e9b9ce7c127a" /> </resourceTargets> </item> If the "resourceTarget" is missing, this is an indicator you may have the issue.
Resolutions 1) Policy was not linked/enabled "properly".
By default, the resourceTarget line mentioned above is not in the Preboot Configurations policy XML. The resourceTarget line is added to the policy by clicking on the 'Save changes' button. Note: In a future maintenance release the resourceTarget will be added by default upon installation. To add the target do the following:
Go into the Preboot Configurations, and using the top-right on/off button, disable the policy. Click Save Changes.
Enable the policy with the on/off button. Click Save Changes.
Verify there is a target by checking the XML (see the diagnosis section). If not, you may need to perform some of the other steps below.
If the policy is enabled and 'Save changes' is not selected the target will never be present in the policy.
2) Target was either deleted or failed to install
If the target is missing from the DB, and the above step did not correct it, you may need to re-run the configuration portion of the installation with AexConfig. This is essentially harmless and is commonly used for fixing issues like missing packages if something interrupted the installation process.
On the NS, run the following either from a command prompt or from the run line:
Substitute the appropriate locations. What is shown are the default installation locations which might need to be modified.
When it is finished, re-run the SQL query. It should return a single row. If so:
Go to Settings > Notification Server > Resource Membership Update and run the Complete Resource Membership update task. Allow it to complete.
Click the Save Changes button on the following policies:
Settings | All Settings then Settings \ Deployment and Migration \ Symantec Boot Services (PXE) \ Preboot Configurations
Settings | All Settings then Settings \ Deployment and Migration \ Symantec Boot Services (PXE) \ PXE Server Configuration
Re-check the XML. (see the diagnosis section)
3) Hierarchy Replication breaks it .
You can verify this is the cause by looking at the top-tier server to see if a target exists in it's XML (see the diagnosis section). If not that may or may not indicate a problem, but either way, that missing target will replicate. If so, here are some possible solutions:
Ensure the Top-tier server also has a target. To do this, you essentially have to successfully configure the top-tier server to use PXE. Once that policy has a configuration, then it wont over-write lower-tier servers.
Break the replication. Unfortunately, you can't break the replication in a supported way, but you can work-around it.
Go to the lower-tier Hierarchy server, find, and then clone the policy. NOTE: The policy can't be named during cloning and will take on the original name. However, you can rename it after it's created.
Disable the original policy, and enable the cloned policy. This policy has all the same features as the original, except that it will not be a part of the hierarchy replication.
Only work in the cloned policy moving forward.
Remember when you finish to verify the new policy has the target (see the diagnosis section)
Whether or not this resolves the issue, please report this to Support so they can properly track the issue. Thanks!
DS 7.1 running on NS 7.0 SP4
ID: ETK 2027390
Logged in Etrack (Symantec) database
ID: ETK 2029214
Logged in Etrack (Symantec) database
Imported Document ID: TECH127398
Subscribing will provide email updates when this Article is updated. Login is required to Subscribe