Our network requires the user to register their computer on the network to obtain network access. This really isn't for security, but for tracking reasons. This registration is done via the web on a temporary private network they get sent to if the dhcp server doesn't recognize the machine. Once registered they can either reboot and renew their IP or just wait till the IP times out which is 2 minutes to gain access to the network with a real IP. The tempoary network runs 2 minute lease times because of the limited number of IPs and the large turnaround we have on this network during peak times. The real network runs 4 hour lease times mainly just because of the large turnaround of computers some buildings have been reduced to 1 hour because at 4 hours we would run out of IPs for the building. We have a class B subnet for realIPs that all clients get with IPv4 we have to play a delicate balancing act to keep from running out. We have in the process of implementing IPv6 which could solve some of these problems.

Back to my problem. When a bare metal computer comes in the tech needs to load the machine. At this point it is on the tempoary network. The tech boots the computer into pe either cd or pxe. Then they register the computer with configmgr and start up the correct task sequence. Even with the 2 minute lease time the client maintains constant connectivity no matter how long the user takes to register the client. You can wait days if you like. Once the task sequence is chosen and it starts to apply the image it will fail. If you push F8 and do an ipconfig it shows a 169.254.x.x ip address. If you try to renew the IP you get An error occurred while renewing interface Local Area Connection : The requested address is not valid in its context. You can release and renew and get a new IP, but at this point the task sequence has failed with error 0x80070035. This is a problem with all model computers even in vmware.

Has anyone experienced this problem? I've seen other post before and the solution was always to bump up the lease time which the network guys won't and probably can't do. It is like the IP will not auto renew while downloading an image.This happens whether you do download as needed by task sequence or access content directly. We are in native mode, but had the same problem in mixed.

Wow, that is a bizarre network configuration. (Why are you using your public class B for internal clients? Why not using private IPs? With lease times as you've described and the number of systems you've described, I would bet that a lot of bandwidth is chewed up just by DHCP.)

Why not set up a separate VLAN for building bare metal systems that is not constrained by the above lease times?

What does "Then they register the computer with configmgr" mean? There is no registration process with ConfigMgr. Are you talking about importing a computer resource because you don't have any unknown computer support?

We need to be able to image bare metal computers from anywhere on the network so using a dedicated vlan is difficult. The requirement for network registration during the setup process has been a problem for years, but with little resolution between the techs and the network guys.

We are using public ips for clients because many years ago the routing hardware couldn't handle the NAT translations for the large number of clients. The network guys don't have dynamic vlans configured although I think they are working on it right now they just piggyback subnets on interfaces. Also the separate vlan for loading computers would be partially difficults since this has to work any all buildings, but because of potentialrouting problems they don't put a vlan in more than one building. Each building right now has at least 1 dedicated vlan with a corresponding subnet and router. Most of our core is 10Gb with at least 2Gb-10Gb to each building so bandwith usually isn't a problem. The DHCP server is old, but handleing the work load just fine.

Our environment doesn't 100% match the typical corporation that runs configmgr. We have a primary central support area and then many sub support areas that all do their own thing with special image requirements. There is a need to keep these areas separate, but centralliy manages with minimal administrative overhead. So to handle this we use unknown computer support just tomake bootingwith pxe into PE. I then use tsconfig.ini to call a modified version of the unknownsystem.hta from the configmgr sdk. The tech doing the imaging logs into this screen and selects an image collection (the available list is based on the users rights to the collections), ad ou, custom variable settings, and machine name to add the computer to the system and recieve the appropriate os advertisements without having to add the system manually through the configmgr console.

We are still working on ways to avoid the network registration step or register the computer on behalf of the client, but would still like to figure out this problem.

Thanks,

Sam

I'm assuming that your unknownsystem.hta connects to the network and you have connectivity when it starts. I don't know why PE releases the address and then why it can't get a new one when the OSD tasks start. It's obviously having difficulty because of your DHCP configuration. Does a task sequence complete without the hta?

It's time to open a case with CSS as only they can begin to answer why PE is releasing and not renewing -- I suspect that this may be by design as PE is not meant to handle DHCP renewals, but I don't know that for sure. They may end up telling you that the whole scenario is unsupported but may give you some clues or help you come up with work-arounds or alternatives.

The problem is it will release/renew without any problem in PE.I can manually copy down a wim file and it will continue to copy and renew theIP.It appears to be related to the apply os step. I'm working on doing some packet captures to see if the client is attempting DHCP at all.

Sam

I'm still having this problem in 2012.  It appears that when starting the task sequence from in PE it will not renew the ip address until a reboot.  If I place a reboot at the beginning of the task sequence everything will work just fine for the rest of the task sequence.  Not exactly the solution I'm looking for, but it works.  I've also seen the same problem if I don't put a reboot in before user state migration restore is done at the end of the task sequence.

Sam

I fought with this same problem for the better part of a week and thought I would update this thread even if it is rather old now.  Maybe it will help somebody else who stumbles across it later.

What I discovered is that the initial IP renewal doesn't happen if the computer was booted via the PXE process.  If you watch via running ipconfig /all, you will notice that the first renewal request never goes out.  We also watched the DHCP server and it never saw a request for renewal.  If you simply type ipconfig /renew from the command prompt one time before it expires, it seems to fix whatever was broken and it will continue to renew and everything should finish normally.  So to work around the issue, you could put in a reboot as Magic280z suggested, but it's quicker if you just run a renew option.  What I ended up doing is; just after the Partition Hard Drive step of the task sequence, and before the Apply Operating System step, I put in a command line that looks like this:

cmd.exe /c ipconfig /renew

This fixed our issues of address timeouts.  -  Do NOT do an ipconfig /release before doing the renew.  Once you do a release the whole thing is dead.  Just run the renew one time and it should kick everything into working.

I also noticed that booting from CD Media made from the SCCM console works just fine.  It does not suffer from the same renewal problem.  We only saw the problem when PXE booting.  And it only affected machines that were in subnets with shorter DHCP lease times. (We have some that are only 30 mins, and some that are as much as 4 hours.)  Short lease time and large WIM file is where we were having problems.  This also could explain why a number of times we would get a successful image but it failed to join Active Directory, or perhaps install the applications from later in the task sequence.  It just depends on what stage of the task sequence it was in when the DHCP lease expired and it failed over the the 169.254 address.