Table of Contents
Advertisement
Distinguishing Internal, External, and Partially-Managed IP Objects in Vi-
talQIP
IP Objects created in the VitalQIP GUI or CLIs will have Object Classes such as Server,
Router, Workstation, and so on. But when A and PTR records are imported into VitalQIP
from DNS via qipsyncexternal or External Updates, VitalQIP might need to create new IP
Objects. If VitalQIP receives an A record or PTR record for an IP address which is within
a known subnet and with a hostname within a known domain, it will create a new IP
object whose Object Class is "External". These objects may not be modified in the GUI
or CLIs, unless the Object Class is changed first. But External objects may be modified
by further external updates or qip-syncexternal. The A or the PTR checkbox of the object
will get unchecked if a Delete is received for the A or PTR, and the external object will be
"tombstoned" in the GUI if both are unchecked. On the other hand, if VitalQIP gets an A
record or PTR record from an external source and that record is in conflict with an exist-
ing IP object that is not "External", the A record or PTR record will be rejected.
Also, VitalQIP 6.1 SP1 or higher has an intermediate Object Class called Partially Man-
aged objects. These objects are created and deleted by VitalQIP Administrators, but
can be modified (such as changed hostnames) by external updates. Partially Managed
objects can be created for important Windows 2003 systems with static IP addresses
that need to be in VitalQIP before they are deployed on the network. This will allow the
addresses to reserved in VitalQIP, but for the hostnames of these IP addresses to be
changed later via qip-syncexternal.
In this solution, the parent domains might have a mix of static IP objects defined in
VitalQIP, external objects, and partially managed objects. But the DHCP child domains
would not have these; they would contain only dynamic IP objects defined in VitalQIP.
Defining DHCP Scopes
When the VitalQIP environment is first set up, the qip-msextract utility can be used to mi-
grate the existing MS-DHCP data into the VitalQIP database. At this time, those objects
should be defined as Dynamic since they will be pushed to MS-DHCP as addresses that
can be leased out.
When new scopes are defined in VitalQIP later, those scopes should also be Dynamic
objects. For MSDHCP servers, all objects in the scopes must be either "Dynamic DHCP"
or "Manual-DHCP". Manual- DHCP corresponds to "Reserved" addresses in MS-DHCP
terminology: the address is reserved for one specific MAC address, and can therefore
have a fixed hostname. A MS-DHCP server does not have a separate type for Bootp;
it will reallocate a DHCP address for Bootp if a Bootp address is needed. No objects
should be defined with Dynamic Configuration types Automatic-DHCP, Manual-Bootp, or
Automatic-Bootp. Also, for MS-DHCP you should not have more than one DHCP Tem-
plate per subnet.
For Solution 2 especially, DHCP scopes should be created with a domain name such
as "dhcp.example.com" which is a child of the main domain such as "example.com". In
this way, the zone options for each domain can be set correctly, qip-syncexternal can
be specific to the desired data, and security of the hostnames will be less critical. For
example, if a DHCP client has a hostname "www", this will be in DNS as "www.dhcp.
example.com" not as a replacement for the corporate webserver "www.example.com".
16
Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory
Advertisement
Table of Contents
