On this page:
Under requirements and limitations it states:
The client source operating system must be of the same architecture as the Windows 10 image you are installing (x86 or x64).
Does this mean that if I have Windows 7 32-bit systems I can’t do an in place upgrade to Windows 10 64-bit? If not how would I accomplish remotely re-imaging/upgrading?
You are correct, you cannot directly upgrade from 32-bit Windows 7 to 64-bit Windows 10. This limitation is based on the Microsoft setup; even attempting to upgrade using media and click-through setup would not accomplish a 32-to-64 migration.
It is possible with OSD to reimage the system remotely. There are several moving parts to it, so be sure to test before you do any mass-migrations.
The installation guide is invaluable, but the basic flow is
Depending on the model of machine you are deploying, you may also need to use the Driver Library dashboard to import additional drivers. You may need to target these to your model of hardware and the image you are deploying, and may also need to target the drivers to your Win10 PE environment. (I’m assuming you already have a Win10 PE environment setup, I think those are used in the OS Reimage content as well as the Bare Metal content).
You should be prepared to spend some time getting this all set up and working properly, there are several moving parts both within and outside of BigFix that need to coordinate. But once you get it set up, it’s a very powerful capability to have. In my environment we regularly reimage our clients and it is very nice not to have to visit them.
Thanks for the reply Jason. Having the ability to boot to the network remotely is a huge win and was not something I was aware was possible.
One more question. When I try to setup OpenDHCPServer on the Bare Metal server it complains that port 67 is already in use. Does the bare metal server already have a DHCP like server setup on it that is using this port? The process that is using it is rembo.exe.
Yes, the server listens for PXE requests on the same port (“It’s Complicated”).
If you enable the (deprecated) web interface for the OSD server, there are configuration options to allow DHCP and OSD to coexist on the box (without Option 43 configured, the client sends a second DHCP broadcast to discover a PXE server, and when nothing responds the client assumes the same address as the DHCP server). I don’t know whether there is a Fixlet/Task to do the same.
I think generally it’s recommended to put DHCP on another machine but it can be made to work if they’re on the same machine.
The longer version is, that there are a lot of different ways to configure the environment. In the simplest form, single-subnet, your PXE client boots and broadcasts to find a DHCP address and is serviced by the DHCP server. After it gets an address, it broadcasts again to find a PXE server. In a single-subnet, REMBO hears this second request and services the client.
In a multi-subnet environment, you might have DHCP servers on each subnet (often serviced by the routers), or you can configure the routers to forward the DHCPDiscover broadcast packets to the DHCP server (Cisco calls this “ip helper-address X.X.X.X”). You could configure the routers to also forward DHCP broadcasts to the OSD server and Rembo would service PXE via broadcast discovery.
What’s more commonly done is for the router to only forward the broadcasts to the DHCP server, and configure DHCP options on the server for PXE discovery (Options…something and Option 43). When the client sees these options, it is informed of the PXE server’s address and any PXE menu options. Then the client can contact the OSD/Rembo server directly without further DHCP broadcasting required.
When I ran OpenDHCPServer on a separate system I was able to get it to boot to PXE. I had tried disabling option 43 but that did not work but I think that should be fine. However I don’t see the options below in OS Deployment and Bare Metal Imaging. Do I need to enable more sites on my BES server?
When the system boots, it will check in to the Bare Metal Server and register a new Bare Metal Target. This appears in the BES Console as a computer account, with an Agent Type of ‘Proxy - Bare Metal Extender’. It will likely be named for its IP address.
From the BES Console, there is a task in the OSD site to deploy your system profile to bare metal targets. The Description tab has menu entries to select the Image/Profile to deploy. You would action this against the Bare Metal Target for this machine.
Make sure that ‘Shownon-relevant content’ is selected. I’m afraid I’m away from a console at the moment and can’t retrieve the task ID numbers for this, but it’s in the normal “OS Deployment and Bare Metal Imaging” site.
I think I figured it out. I had limited the computers that were members of the site by properties that the bare metal machine did not have. I have instead enabled the site for all computers so it should show up soon. Also the fixlet Deploy Profile on Bare Metal Targets is in there. As soon as it displays the PC as relevant I will test deploying it.
I figured out the real real problem. I didn’t have the proxy agent installed on my relay.