PXE Boot Server Forwarding
DSM OS Deployment (OSD) allows you to run several deployment systems parallel in your DSM environment which 'receive' the computers when they boot from the network. For this purpose, DSM provides PXE boot server forwarding. The following deployment systems can run parallel, for example:
• DSM OS Deployment, also several installations
•Enteo v6 OSD,
•Enteo OSD 3.x,
•Citrix Xen Provisioning Server, and
•some other deployment solutions.
Requirements
To guarantee a smooth operation of the different systems with network boot functionality, please make sure that DSM is the leading system for managing the computer's PXE boot requests.
This requires you to set up the Relay Agents or IP Helpers in your network in such a way that the computers contact the OSD Proxy. The OSD Proxy ensures for the distribution of the requests to the other systems with network boot functionality. the computers also contact the DHCP server.
Please also note the following requirements:
•The computers must not access any other boot server by network broadcast.
•Do not set any options for the network boot on the DHCP server (options 66, 67, 60, 42, etc.).
You can run two DSM environments or one Enteo v6 and one DSM 7 environment parallel. You can implement this by a black and white list or via PXE boot server forwarding.
Rules for Forwarding
PXE boot server forwarding will only work if no OSD specific rules for network requests of computers exist.
The OSD Proxy decides on the computer's network requests according to the following rules:
•Is the computer excluded from network boot?
If the computer has been excluded from PXE network boot, nothing happens and there are not further actions. Exclusions are defined in the black and white list of the OSD PXE Service. Please refer to Chapter "Using the Black & White List" on page 8 for more details on the configuration.
In theory you could also run several PXE boot servers parallel and achieve PXE forwarding by defining an exclusion list for the OSD PXE Service. However, this solution with the INI file is difficult to configure; also, some parallel systems do not support exclusion lists.
•Is a boot environment required for executing the OSD package?
If a computer is not excluded from network boot by the black and white list, the OSD Proxy checks whether there are OSD packages, that require a boot environment, waiting to be installed on the computer. If this is the case, the OSD Proxy installs these OSD packages with a higher priority. There is no PXE forwarding in this case.
Post OS Action Packages and Universal Script Packages do not require a boot environment.
•Is there a Self-Service package that needs to be executed?
If there is a Self-Service package that needs to be executed for the computer, PXE forwarding will not work.
•PXE boot server forwarding?
If a computer has the permission to boot from the network and the OSD Proxy does not have any other tasks for this computer, the boot request is forwarded to the respective system. The system has to be introduced to the OSD Proxy before. This can be done by specifying values for some variables for the computers in the DSMC. Please continue with the following chapter for more details.
Configuring Forwarding with Variables
There are a number of system variables available for PXE boot server forwarding. You can find these variables in the BootConfiguration variable group. They are visible in the DSMC's Configuration detail tab in the context of computer objects. With the help of these variables you can specify the PXE boot server the individual computer will be forwarded to by the OS Proxy.
You can define an alternative PXE boot server as follows:
•Boot server IP - Enter the IPv4 address of the alternative PXE boot server here.
•Boot File Name - Enter the link to the boot file here. Enter the value ardbp32.bin for the Citrix Xen Provisioning Server.
•Boot Server Type - If you are running a parallel DSM 7 or Enteo v6 environment, please enter the boot server type 0xFFF1 here instead of a boot file.
If you are running the Enteo environment with OSD 3.x, please enter the boot server type 0xFFF0 here instead of a boot file.
More boot server types are possible, however, the type depends on the respective boot server.
If a value is assigned to a variable or if the variable value is changed later, this does not lead to a push job. The same applies if a computer becomes a member of a group or is removed from it. In both cases you must update the OSD Proxy manually. Please refer to Section Updating the OSD Proxy for more details.
Use the following list to determine which variables you will need to enter
1.If there is no alternative PXE boot server: Leave the variables empty.
2.The alternative PXE boot server provides TFTP services only: Enter the Boot server IP and Boot file name variables as needed. The client will then be prompted by the OSD Proxy to fetch the respective boot file from the alternative PXE boot server.
3.The alternative PXE boot server fulfills one of the following requirements:
•It "listens" on port 67 (prerequisite: OSD Proxy is not running on the DHCP server)
•It sends its own PXE boot menu to the client
•It is an OSD Proxy (e.g. from a test environment)
Enter the Boot server's IP variable only. This variant can be used in most instances. Client requests will be received by the OSD Proxy and then be redirected to the respective PXE boot server. This boot server answers the client request.
4.All other cases: Enter the Boot server IP and Boot Server Type variables as needed.
Specifying Variable Values for Groups
If you do not want to specify the above variables individually for every computer object, you can create static or dynamic computer groups in the organization tree of the DSMC. The variable values are passed on to all group members.
We recommend specifying variable values via groups where possible. This considerably reduces maintenance time.
Updating the OSD Proxy
The OSD Proxy (acting as "proxy" of the computers it is responsible for) runs a synchronization against the Business Logic Server (BLS) and stores the information, the data and the upcoming tasks for the computers in its cache. When the computers contact the OSD Proxy when booting from the network, the OSD Proxy must be up-to-date. If there are changes, the data is automatically forwarded from the BLS to the OSD Proxy with a push job. A push job starts, for example, when OSD packages are assigned to computers.
In the following cases you must update the OSD Proxy manually:
•A value is assigned to one of the above variables or its variable value is changed later. A computer becomes a member of a group or is removed from it and this changes the variable value of the above variable.
•A push job was not created or gets lost on its way to the OSD Proxy.
The two following methods are available:
•The task OSD Support Tasks › Update on OSD Proxy in the context menu of a computer object.
•The task OSD Support Tasks › Refresh OSD Proxy cache in the context menu of the ORG object in the organization tree of the DSMC. This updates the DSMDB cache on the OSD Proxy.
Please execute both tasks with caution! They lead to increased system activity.
The Task 'Update On OSD Proxy'
Use the task Update on OSD Proxy to update the data of a computer in the OSD Proxy cache. For this, the Business Logic Server (BLS) sends a push job to the OSD Proxy that the client contacted last (computer property Last Boot Server). If several computers are selected, a push job is created for each one of them. The computer properties Last synchronization and Agent of last synchronization=OSD indicate when the client synchronization happened.
Example: If you select 100 computers and update your entry in the OSD Proxy cache, the system creates an individual push job on the BLS for each computer. In turn, every push job leads to a client synchronization. The client syncs have no limitation on the amount of data they synchronize.
The Task 'Refresh OSD Proxy Cache'
Use the task Refresh OSD Proxy cache if you want the BLS to send one single push job to the OSD Proxy containing the instruction to refresh its cache. The updates are performed as synchronizations of the OSD Proxy against the BLS. A maximum of three synchronizations may be performed parallel per OSD Proxy. This keeps the system load low. The beginning and the end of the update are reported as infrastructure event. You can view these events in the Infrastructure Monitoring › Events of DSM Web.
The OSD Proxy performs a synchronization for every client against the BLS. During this process the system also deletes computers from the cache that do not exist any more.
Typical use cases for this task:
•The server where most computers are forwarded to is specified the first time and changes later.
•The variable value for OS Self Service is specified the first time or the boot environment used for OS Self-Service changes.
Please use the task Refresh OSD Proxy Cache with caution. It leads to increased system activity.
Example: You run the task Refresh OSD Proxy Cache for an OSD Proxy that manages 5000 computers. This creates a push job and initiates 5000 client syncs, three of which parallel. If there are only few changes for few computers, we recommend that you run the task Update on OSD Proxy and select the respective computers with multi-select.