Yes. The static IP address is assigned at the time of the configuration of the TCP/IP stack as it does in a normal Windows unattended installation. You do not have to worry about connectivity at this point, because the app server is just waiting for this OS setup piece to finish and then hear the next call from the boot process on the next reboot.
In order for provisioning to continue to work though, the static IP address should be of the same subnet as the vlan as the app server will need to communicate via that address after that reboot in order to recieve the call for the next instructions.
If you use the options in the provisioning package to join the server to the domain, the provisioned server will need to be able to talk to the DC's in order to complete the domain join, just as in a Windows unattended installation.
Thanks for the quick reply, Adam. This poses a question about how we're going to make this work in our environment.
All servers live in racks in our data center, which has it's own general production network. Each network switch port in the data center is statically assigned to a IP address. The server is then connected to the correct port. We do not allow a DHCP server presence on the data center network. This is why we are creating an isolated provisioning VLAN to host the DHCP server. This isolated VLAN will be located in our test lab, so the plan was to have new servers brought into the lab, connected to the provisioning VLAN, have BladeLogic Provisioning Manager build the server (and assign the correct IP), then move the server out to the data center in its final destination.
But it sounds like the provisioning manager will want to switch over to the assigned static IP before provisioning is completed, which will not be possible with our current setup. Is it possible to build the OS, assign the static IP, then stop the job at the next reboot so we can move the server to its data center location and then restart the job after the server reboots?
Do you have any suggestions / alternatives for us to be able to use the provisioning system while still keeping the DHCP server isolated from the regular network?
You are not the first to have this conundrum, and I have done this a couple of different ways.
It sounds like you will have one BL implementation in your test lab that is autonomous of your production instance. In this case, I would do the following:
1) Provision without specifying a static IP or joining to the domain.
2) Move the server to the Production network.
3) Add the server to the production instance of BladeLogic
4) Initiate a batch job in the production instance to the server that sets a static IP (a little bl-tivity is needed here, so you can email me if you need help) and join the machine to the domain.
Glad to hear we're not the first...!
How do we connect the server to the production instance of BladeLogic if the server doesn't have an IP address at this point?
Also, would we need to have BL Configuration Mgr and Provisioning Mgr setup in the test lab or just the Provisioning Mgr? We were actually planning on accessing the production instance from the lab, so it only needed to be setup once. But we can probably bring up another instance.
ha! yeah, apparently I am being stupid for a moment. You are right about the IP address. You could make post-provisioning batch job that places a netsh script in the startup directory and deletes its self after the execution. So when you power it on in the production network, the server is configured with the correct IP.
The problem with the provisioning manager in the the test lab and the appserver in the production network is that the server being provisioned needs to communicate with the appserver. It is the appserver that tells the provisioning server to move to the next step and to send the next instructions on the reboot. The only thing that listens on the provisioning server is pxe, dchp, tftp, and file sharing.
Don't worry, I'm still learning the provisioning details so I'll probably have just as many (or more) of those moments. I spent some time reading the Windows provisioning process in detail so I understand it a little better now. The self-destructing startup script sounds like a good option. I guess we would just need to pause the provisioning process before the network settings are applied, so we could move the server. This would be possible, correct?
How is the provisioning process continued once we move the server? The best-case scenario would be to have Windows load up for the first time after the move, so the IP could be set. Once it's in the data center, I don't think the server will have access to the data store any longer, so hopefully all the OS software and the RSCD agent would have been transferred by this point. Would it be?
(Sorry for all the questions, trying to make sure I don't miss anything!)
Yes, you're right about the provisioning manager, the install guide states that it needs to be installed on the same server as the app server. So we would have to open up firewall ports to provide access to the BladeLogic production environment from the provisioning VLAN. What port do the new servers use to communicate to the provisioning manager? 9831?
Sorry it took me so long to respond.
No need to pause the provisioning process. Just let it complete. You have the option for a bladelogic batch job to be initiated at the end of the process. This batch job could be an simple job that just puts the netsh script in the startup directory and sends the server a shutdown command.
Then you would just move the server out to production, add it to the bladelogic production instance, and start it up. On start up the netsh script would set the static IP settings. Then you could use the production instance to do any additional configuration items, like joining the server to the domain.
To answer you last question, the calls do happen via TCP 9831.
Thanks, this sounds like something we will probably end up doing.
If, for some reason, we are unable to get a DHCP server in our provisioning environment, is there any workaround at all to still be able to install the OS onto the bare-metal servers? Is there a way the PXE server can recognize the server via MAC address instead of IP?
No, not really. The PXE process needs to assign the IP address for unicast traffic to flow. After the DORA sequence is complete, it then initiates a tftp transfer to copy the bootstrap and instructions which can only be done (in the PXE way) via tftp options defined in a DHCP scope.
I think there's another way to do this - you can hardcode the IP address and the bladelogic info (port, server) in the winpe image, and convert the winpe.wim to an iso that you can boot off a cdrom (or maybe usb key)
i think the problem there is that you'd have to know when to eject the cdrom (after the windows install process starts) otherwise you'd be always booting into bladelogic.
In other words, we would just skip the automated process of receiving the boot image (which relies on PXE/DHCP) and provide the boot image ourselves?
The other way we could boot the image is via virtual drivers through the iLO/RSA card. This is similar to what we do now except that instead of the boot image loading into BladeLogic Provisioning Manager, we load into a WinPE environment and then use ghost to apply the OS image.
In other words, we would just skip the automated
process of receiving the boot image (which relies on
PXE/DHCP) and provide the boot image ourselves?
the critical part though is that reboot midway through the process - you want it to boot off of the iso to talk to bladelogic, and start the provison process. but after that, you want it to boot off the local disk.
the pxe server takes care of that bit because it knows where the box is in the provision process and when the target requests a boot image, the pxe server says "oh, you're at step 11, you need to local boot" or "oh, you're at step 5, you need to boot off of the boot image"
I see what you mean. If there was only one reboot to worry about, it wouldn't be that big of an issue. I think there is a setting to have the iLO/RSA card boot a certain way one time. However, for multiple reboots, I guess you would have to be watching the installation to make sure you didn't miss it (which defeats the purpose of switching to an automated provision process).
I do not think this would be an issue. If you set it to always boot to the HDD first, then to the CD-ROM as secondary, then the operation should proceed correctly. Of course, this would only work for a box with no bootable OS (a fresh install) on the HDD.