none
Unable to authorize DHCP server under Active Directory

    Question

  • We are running W2K8 R2, and had successfully started running DHCP.  But, because of a need to remote boot a new machine we needed to add Active Directory to the server.  After adding Active Directory our DHCP server would not run, saying that it first needs to be authorized.  However, there is no option (either under the Action menu or when right-clicking on the DHCP server) to authorize.  We thought that maybe the problem was caused by DHCP being on prior to Active directory, but even after removing DHCP and then adding it back we get the same problem.

    Can anyone help on this?

    Rick


    Rick
    Monday, August 23, 2010 1:31 PM

Answers

  • Unfortunately, nothing was actually resolved from what we originally needed to do.  To resolve the DHCP issue we had to remove all relevant services and re-add them, losing all user accounts at the same time, so we almost had to start from scratch.  And, the creating a terminal is apparently not possible with Windows Server, so we are back to just using an XP machine and logging in with RDP, which is exactly what we were trying to change.

    I do appreciate the help that everyone tried to give, but ultimately we just went around in a big circle and have ended up back where we started.

    Rick


    Rick
    • Marked as answer by Brewhaus Thursday, August 26, 2010 2:14 PM
    Thursday, August 26, 2010 2:14 PM

All replies

  • you can authorize it in the dhcp wizard when you add the role. step by step win 2008 dhcp server

    http://www.windowsreference.com/windows-server-2008/how-to-setup-dhcp-server-in-windows-server-2008-step-by-step-guide/


    Roy Mayo | MCTS • MCSE | USA
    Monday, August 23, 2010 1:44 PM
  • These are the exact same instructions that I followed, so here is the issue that we hit:

    The DHCP server that was installed prior to Active Directory showed as not authorized.  There was no place for us to select "authorize", so we removed the DHCP role.

    When we rebooted and tried to add the DHCP role we received two errors at the end.  The first error stated that there may be a conflict on the scope, so I am guessing that, even though we had removed the DHCP service, somewhere it still had the scope listed.  The second said that the attempt to configure DHCP failed with error 0x80074E66.  The DHCP service could not contact Active Directory.

    We just tried removing the DHCP service and re-adding it, but entered a different range on the scope.  We still got the second error above.

    Any thoughts?

    Rick


    Rick
    Monday, August 23, 2010 2:35 PM
  • Can you send the error IDs for the two errors?
    Monday, August 23, 2010 2:55 PM
  • http://support.microsoft.com/kb/303317

    http://support.microsoft.com/kb/246603/

    are you using domain admin credentials?


    Roy Mayo | MCTS • MCSE | USA
    Monday, August 23, 2010 3:07 PM
  • The first error is:

    Attempt to configure DHCP server failed with error code 0x80074E54.  the scope parameters are incorrect.  Either the scope already exists or its subnet address and mask is inconsistent with the subnet address and mask of an existing scope.

    As mentioned, when we tried installing DHCP with a different address range (instead of .100-.199 as we originally had set up, we tried .10-.99) we did not get this error, but still received the error noted in the previous post (code 0x80074E66).


    Rick
    Monday, August 23, 2010 3:23 PM
  • We have tried using three different accounts (all admins) to install DHCP, but none have worked.  Maybe I should remove both roles (DHCP and Active Directory) and start from scratch to see if that will help, as I do not know what else to try.
    Rick
    Monday, August 23, 2010 3:46 PM
  • sounds like it's defined in ad eventhough it's not authorized.  this article shows how to see it a dhcp server exists in ad by using adsiedit.

    http://support.microsoft.com/kb/306925


    Roy Mayo | MCTS • MCSE | USA
    Monday, August 23, 2010 3:46 PM
  • For the DHCP service, I found on the internet that detecting another DHCP server may cause problem. Make sure you have not another DHCP server which is running (router, server ...).

    Best regards.

    Monday, August 23, 2010 3:50 PM
  • Not pretty, but by removing DHCP, Active Directory, and DNS (which removed user accounts, as well, but fortunately there were only a couple and they ran just a couple of installed programs), and then starting from scratch, we were able to get DHCP working under Active Directory.  Now we just have to rebuild the couple of user accounts.

    Quite a nightmare, but I assume it had something to do with DHCP being installed and active ahead of adding Active Directory, as we did everything the same after complete removal, just in a different order.

    Rick


    Rick
    Monday, August 23, 2010 4:58 PM
  • Hmmm- one other issue that seems to have popped up now.  We can no longer RDP in using the public IP address.  A computer on the network can RDP in using the internal IP address (192.168...).  Is there something that we need to do to allow public access again?  Our router has not changed, and we did have access previously.
    Rick
    Monday, August 23, 2010 8:00 PM
  • Even if it has not been changed, check if the router if forwarding correctly the traffic for the public ip address to the correct ip address (If you had changed the server IP address, it is the cause of the problem).

    If you are able to send a ping request on the public ip address, check if you have blocked a port (On a router/firewall) which caused the connection to fail.

    Best regards.

    Monday, August 23, 2010 8:18 PM
  • I am feeling kind of stupid now... I did change the server ip address, and just never thought of the implications on port forwarding.  Maybe I need to take a break from this to let my brain catch up to all that I have done.

    I think that the only remaining issue is remote booting via WDS.  Should I ask that here (it is still to do with the network infrastructure), or start a new thread?  If I can ask here- is there anything to set up (TFTP) to tell the remote computer where to find the boot information?  The remote computer is getting an address from the server, but the PXE boot is aborting.  Also, can a 32-bit machine be booted remotely from a 64-bit server?


    Rick
    Monday, August 23, 2010 8:28 PM
  • Hi,

    Can you tell us what are Servers now you have in your network: example DC, DNS, DHCP, WDS..ets and can you give us the TCP/IP settings for each one. And please can you add the options that the DHCP Server delivers.

     

    Regards,

    Monday, August 23, 2010 10:17 PM
  • The server is running Active Directory, DHCP, DNS (internal only), File Services, and WDS.  There are three connections (printer, time clock, laptop) getting dynamic IPv4 addresses from the server, and one that has a static address.  We are trying to get another computer to boot over LAN.  It is an older 32-bit system.  It does appear that the computer is getting an ip address, and then it says 'downloading WDS***', followed by Press F12.  We press F12, but it still aborts the boot.
    Rick
    Monday, August 23, 2010 10:26 PM
  • This is the first time that we have ever tried to boot a computer over LAN.  The only other computer running on the network has Vista installed on it.
    Rick
    Monday, August 23, 2010 10:50 PM
  • I asked a such question because:

    1- If only one client computer is facing this problem, the problem is with the computer

    2- If all client computers are facing the problem, the problem is with the WDS server

    Check if there is any error messages on the server.

    Best regards.

    Monday, August 23, 2010 10:52 PM
  • Hi,

     

    To authorize the DHCP SErver, the DHCP Server itself should be joined to the domain..after you join it to the domain you have to log in to using the domain administrator account..after this log in to the DHCP management console and authorize it.

     

    Regards,

    Tuesday, August 24, 2010 7:37 AM
  • We have only one computer here that can be set up to LAN boot.  Even my computer from home is not able to LAN boot, so I cannot bring it in to test.  But, the computer that is supposed to boot over LAN is getting an ip address from the server, and it is downloading a file from WDS.  It then asks for the user to press F12 in order to boot, and either the computer is not accepting our input or there is some other reason that it is aborting the boot.  I read somewhere that it is possible to change the settings so that there is no user input required, so I would like to try that.

    I guess my two questions are:

    1- Is there anything that we need to set up beyond Active Directory, DNS, DHCP, and WDS for the server to allow a computer to boot remotely?  Does WDS take care of telling the remote computer where to find the necessary files to boot up?  I assume that it does, as a file does get downloaded from WDS when we try to boot remotely.

    2- Will a 32-bit computer be able to boot remotely from a 64-bit server?  I assume that it can, but you know what they say about assuming...

    Rick


    Rick
    Tuesday, August 24, 2010 3:40 PM
  • We finally managed to get DHCP authorized, although it was a tremendous headache.  It took removing all of the associated services, which took all user accounts with it, and then adding the services back in order.  A pain, yes, but it did work.
    Rick
    Tuesday, August 24, 2010 3:42 PM
  • Great for the DCHP server.

    About the WDS, I am not an expert for this kind of service but I have a Microsoft article named "Windows Deployment Services Getting started Guide". It may help for the configuration of the WDS server.

    The link is the following:

    http://technet.microsoft.com/en-us/library/cc771670%28WS.10%29.aspx

    Personally, I think you have a problem with the boot image.

    Best regards.

    Tuesday, August 24, 2010 3:59 PM
  • I notice in the instructions that the computer that is booting remotely must meet the requirements of the software that is booting it- in this case it needs to be 64-bit and is not.  That is most likely our problem.  We will need to get a 64-bit computer that can boot remotely to test that theory before we purchase a new mboard and CPU.

    One further question- will the remotely booted computer be a 'dumb terminal' that is actually running on the server, or is it a standalone computer that would have to RDP into the server in order to access the files on the server?  What we want is a terminal that is actually running on the server.

    Rick


    Rick
    Tuesday, August 24, 2010 4:44 PM
  • According to my knowledge, I think that the client computer would have to RDP into the server in order to access the files on it. The execution of the files will be on client computers.

    Best regards.

    Tuesday, August 24, 2010 5:28 PM
  • Damn- that is exactly what we were trying to avoid.  Do you happen to know how we set the remote computer up as a terminal that runs on the server?  RDP is only half-@ss useful- it is slower than working at the terminal, a person has to physically log in remotely, printers must be selected with each login (because Server, in its wisdom, sets up 'copies' for RDP clients, and they never work), and things such as side buttons on mice do not work.  It works fine for a quick job or troubleshooting, but nothing more.
    Rick
    Tuesday, August 24, 2010 7:07 PM
  • Do you happen to know how we set the remote computer up as a terminal that runs on the server? 

    I am not used to configure WDS.

    By the way, I have an excellent Microsoft guide that will show you all the possible configurations of this service:

    http://www.microsoft.com/downloads/details.aspx?familyid=14CA18B1-B433-4F62-8586-B0A2096460EB&displaylang=en

    Have a look at it il will give you all the information you need.

    Best regards.

    Tuesday, August 24, 2010 7:22 PM
  • It sounds like WDS simply allows a computer to boot without its own OS installed, but that computer is running just like any computer WITH its own operating system.  In other words, it is not actually running on the server, but as a standalone computer.  Is that correct?  If so, then there is no reason for us to have Server 2008 at all (fortunately we are still running a trial), as we have a version of XP that used to be on the server machine, and can purchase a full version for the other computer for far less than purchasing Server 2008.

    It used to be possible to have a computer without a hard drive that actually ran from the main server.  Is this no longer the case??

    Rick


    Rick
    Tuesday, August 24, 2010 8:35 PM
  • When you will install an operating system, you usually use a CD/DVD, a bootable disk or a bootable USB key.

    With the use of WDS, you can deploy an OS image on the server so that if you want to install your operating system by booting on the server. So, it is just easier like that: You don't have to search your DVDs ... Also you can personalize your desktop and sysprep the OS and then save the image. So, you can deploy the same image for all the client computers. These are some advantages with the use of the WDS.

    After installing the OS, you computer will work as a standalone computer.

    This is what I know about WDS. It is possible that some thing about what I said is wrong.

    Tell me what do you need to implement and I will tell you what to purshase.

    About the computers running without a hard drive, it is possible with the virtualization of your environment and this require specific hardware (Blades ...).

    Best regards.

    Wednesday, August 25, 2010 12:18 AM
  • In short, we do NOT want to have to log into the server using RDP.  I use RDP only when I need to, as it is far from the same as being at the computer that you are working on.  You cannot save settings for the simple tasks.  For example, we cut and paste constantly, so the side buttons on the mouse are set up to be used for copy and paste actions.  When logged into another computer via RDP you cannot use those buttons.  Scrolling is also very slow.  Also, the printers get multiple instances (redirected 1, redirected 2), and they simply do not work, so every time that you log in via RDP you have to physically select the printer or re-save it as a default.  RDP is fantastic for basic functions, but not to spend the day working on the computer.

    What we DO want is to run a terminal that physically runs from the server- just a second terminal (obviously using a separate login) that runs from the CPU and HD of the server.  When a person is working at that terminal, they are physically working on the server.

    So, what do we need in order to make that work?


    Rick
    Wednesday, August 25, 2010 12:29 AM
  • About RDP, I said it is possible that it is that it proceed like that but this is only during the client computer operating system install process. Once the OS for the client computer is installed, it will work as a normal computer.

    This is a link about WDS. It will explain to you what is this service because I think you have not understood it correctly:

    http://en.wikipedia.org/wiki/Windows_Deployment_Services

    Wednesday, August 25, 2010 12:40 AM
  • What we DO want is to run a terminal that physically runs from the server- just a second terminal (obviously using a separate login) that runs from the CPU and HD of the server.  When a person is working at that terminal, they are physically working on the server.

    So, what do we need in order to make that work?


    Rick

    To do that, you should use specific hardware components and proceed by virtualization.

    This is an a link of an example of these hardware components that can be used (Blade):

    http://en.wikipedia.org/wiki/Blade_server

    A such solution cost too much but it can do what you mentioned.

    Best regards.

    Wednesday, August 25, 2010 12:43 AM
  • This sounds far too complex and costly to run just a second computer off of the same server.  Thank you for your help, but I think that we will just have to abandon this entire project and see what other options may be out there.  I believe that some of our software runs only on Windows, otherwise we would have just selected Linux, as apparently it still does offer the setup that we need.

    Rick


    Rick
    Wednesday, August 25, 2010 12:52 AM
  • I think that the use of Linux is not a real resolution for your problem.

    I agree with you that RDP connection can be a little bit slow but this is an article about how to optimize the use of such connections:

    http://malektips.com/xprdc0005.html

    It is for windows xp but it can help.

    But the problem is that I am not understanding very well what you want exactely. So, please give more details.

    What are the roles and the software that you want to run on the server?

    Why you don't work on your own client computers?

    Why the need to access the server so that it load the client computer OS?

    How many users do you have?

    For Linux, as I know, it is not possible to do what you want to do now.

    Best regards.

    Wednesday, August 25, 2010 1:08 AM
  • I apologize in advance if this gets a little bit long, but I want to fully explain what we need to do and why, and how RDP does not work for us.  Maybe that will help so that you can tell me if it is not possible or if there is some way to do it.

    Right now we have our Server 2008 machine as the primary computer.  It runs all of our necessary software for label printing, order processing (including running our UPS and USPS software), and a couple of special printers.  The UPS and USPS software cannot be run on more than one computer at the same time as they are not built to remotely access the database, so they must be run from one machine (more than one user can run them, providing they are on the same physical computer).  Our label printing also must be run from one computer, as the labels use exact links to the artwork, so we cannot run it from multiple computers.  Also, three of our printers will not run correctly through a USB hub (they are specialty printers, not standard HP printers, for example).  So, all of these things must be run from one computer.  However, we cannot have two or three people needing to do things simultaneously from the same computer.  We cannot simply set the software up on each client computer.

    RDP does allow us to log into the server as a different user and simultaneously run the software, but that is only a reasonable option for occasional use.  RDP is not feasible for constant use of all actions.  Here is why it is not a good option:

    1- It is slower than working directly on a computer, which slows production.

    2- We have to teach everyone who may be on the remote computer how to log in, and the differences between when they work on the server and when they work on the remote computer.  We do not want to become computer school for our staff.

    3- Further to #2, when logging in with RDP the printer defaults always default to the 'redirected' printers, because the computer knows that you are logged in via RDP.  That means that every time you log in you must reset the defaults or the system will not print (when printing to the redirected printers nothing ever prints).  I learned this the hard way.

    4- Time saving things, such as using a faster scroll speed on the mouse, or setting the side buttons on the mouse to specific uses such as copy and paste, do not work via RDP. 

    As I said before, I use RDP daily, but only for specific, quick tasks such as checking CPU usage, etc., on our other server.  But I really feel that RDP is only viable for such purposes, and not to be on all day every day.  RDP has its place, and it is certainly not as a replacement for having a proper terminal running ON the server.

    So, does Windows Server even offer such a thing?  My brother runs a Linux server and has supposedly set this up, but our software cannot be run on Linux.

    Rick


    Rick
    Wednesday, August 25, 2010 1:59 AM
  • The problem is clear now.

    First of all, I would like that you have a look to this Microsoft link. It is about deploying printers by using Group Policy:

    http://technet.microsoft.com/en-us/library/cc722179%28WS.10%29.aspx

    Just a remark: to deploy that you should have an Active Directory infrastructure (at least one domain controller)

     

    For your installed softwares, you should see with your solution provider about how it is possible to access the server throughout a client software that should be installed on the client computer.

     

    Be sure that Linux will never be the solution for your problem.

     

    Wednesday, August 25, 2010 2:29 AM
  • I will look at the article that you suggested.  Unfortunately, it still does not resolve all of our other issues- speed, training people how to use a second computer because they operate differently, the lack of support for simple features like side buttons on a mouse, etc.  Ultimately, RDP is not a good way to be running a computer- it is only good for brief work on a remote computer such as for troubleshooting.  We must have a real solution, and it sounds like Windows does not offer that, which is unfortunate, as our specialized software will only run on Windows.  I just cannot believe that larger offices run many computers and have all of them as standalones where each client has to manually log into a central computer via RDP.
    Rick
    Wednesday, August 25, 2010 2:54 AM
  • Have a look to this Microsoft article, it is about application server role:

    http://technet.microsoft.com/en-us/library/cc754024%28WS.10%29.aspx

    Best regards.

    Wednesday, August 25, 2010 3:26 AM
  • Thank you.  Unfortunately, it still does not seem to address our real issues of logging in remotely and being able to use things such as custom settings of mouse buttons.  This may seem small, but when a person will perform this task maybe 30 times in a matter of a few minutes, it is quite significant.  And, having to log in every time that the server crashes (we have not had this many crashes since Windows 95), it is just too much training for those who are not well versed in computers.  We need a simple solution that allows the remote computer to act just like it is another keyboard and monitor plugged into the server, but it does not seem like that is possible anymore.
    Rick
    Wednesday, August 25, 2010 3:40 AM
  • There is no solutions simpler that those. Even with Linux, what you want is not feasable. Furthermore, with Linux you should give much trainings for the employee.

    Best regards.

    Wednesday, August 25, 2010 1:52 PM
  • I wonder if I am confusing RDP and RDS.  Is RDS just a new name for RDP?  Or, is RDS something different?
    Rick
    Wednesday, August 25, 2010 2:49 PM
  • Remote Data Service (RDS) is a feature of ADO, with which you can move data from a server to a client application or Web page, manipulate the data on the client, and return updates to the server in a single round trip.

    Remote Desktop Protocol (RDP) is a proprietary protocol developed by Microsoft, which concerns providing a user with a graphical interface to another computer. The protocol is an extension of the ITU-T T.128 application sharing protocol. Clients exist for most versions of Microsoft Windows (including Windows Mobile), Linux, Unix, Mac OS X and other modern operating systems. By default the server listens on TCP port 3389

    Wednesday, August 25, 2010 4:19 PM
  • I haven;t read through the entire thread, but I did catch MS Helper's
    last reply. RDS = Remote Desktop Services,
     
     
     

    -- Mike Burr
    Wednesday, August 25, 2010 4:53 PM
  • Agree with Mike,

    Remote Desktop Services (RDS), formerly known as Terminal Services, is one of the components of Microsoft Windows (both server and client versions) that allows a user to access applications and data on a remote computer over a network, using the Remote Desktop Protocol (RDP).

    RDS is the abreviation of Remote Desktop Services and Remote Data Service.

    I recommand to you to have a look to this link to have a complete idea about the Remote Desktop Service (RDS):

    http://en.wikipedia.org/wiki/Terminal_Services

    Best regards.

     

    Wednesday, August 25, 2010 5:21 PM
  • Just to keep things organized, my two questions are:

    1- So, if I understand, what we really have to do is to use RDP to actually work on the server from another terminal if we want to keep all programs and files entirely housed on the server- is that correct?

    2- If we manage to get remote booting working (I am sure that we will, it is just a matter of getting things right), will the remote computer pull its entire OS from the server?  In other words, when the remote computer boots up over LAN, will it operate just like a normal Windows computer?  Or, if not, will it at least be stripped down but run RDP so that we can be running on the server via RDP?

    Rick


    Rick
    Wednesday, August 25, 2010 7:06 PM
  • 1- If your software can only be installed on a single machine and there is no way to access it remotely then in this case you should use RDP to work on it. Check with your software provider if it is possible to access the software with a Web interface or thing like that. Have a look also to the role application server.

    2- With the use of WDS, according to my aknowledge, the client computer will boot to an OS image hosted on the server so that it install its OS (In this case you don't need a DVD, a bootable USB or a bootable disk to install the client computer OS because you can boot from the server). After the client computer has finished to install its OS, it will not boot up over LAN to start its OS (because the install is made on the client computer). So, you can deploy WDS just to get simpler the install of your client computer OS. I have no idea about the process needed to accomplish this kind of boot but what you want will not be accomplished with the use of this service.

    Another remark: What you want is not feasable with Linux infrastructures.

    Wednesday, August 25, 2010 7:17 PM
  • So, you should see with your solution provider how to let the software accessible by client computers via network.

    Best regards.

    Wednesday, August 25, 2010 7:20 PM
  • I understand that, even if we do not like it, we will have to use RDP to run the necessary software from the remote computer.

    I believe that my only other question is regarding licensing- on a normal license for Server 2008, can the remote computer install the OS under the license?  I assume that it is just considered as one of the client access licenses, but we do not want to break the EULA.  And, if it is allowed, is it also allowed to install from the DVD, as that would be easier seeing as this will only be on one additional computer?


    Rick
    Wednesday, August 25, 2010 7:48 PM
  • Each client computer should have its own license.

    Just to add, you should have a look to the Microsoft Windows Server 2008 editions so that you will know which is better in your case.

    This is a link about the Microsoft Windows Server 2008 editions:

    http://www.directionsonmicrosoft.com/sample/DOMIS/update/2008/02feb/0208ws2plp_ch.htm

    This is a Microsoft article about the Microsoft Windows 2008 R2 editions:

    http://www.microsoft.com/windowsserver2008/en/us/r2-editions-overview.aspx

    Best regards.

    Wednesday, August 25, 2010 8:01 PM
  • If we will require a separate license, then I can simply use the version of Windows that we already have installed on the computer that we were going to boot over LAN.  It obviously comes with RDP, and the ONLY thing that the computer will do is connect to the server and run the software on it.  There is no point in purchasing another version of Windows or Windows Server when we have a usable one that is already paid for.

    Rick


    Rick
    Wednesday, August 25, 2010 8:42 PM
  • Just to clarify:

    You told me that your are running a new server with a trial version. If it is the case then this license will expire after a certain period. So, if you are using a trial version and you want to continue to use this server you should purchase a license for it. In your case, you have a paid license so you can install you software on the server running with it and access remotely to it if you want to work on you software.

    For the WDS, you can deploy images and you made a client computer OS install throughout a LAN boot then in this case you should have a license for this client computer (If you have one then you can continue to use for this client computer (each license is for a single computer) and if not you should purchase one because WDS is only a service for OS images deployment)

    Keep in mind that every Microsoft Windows Operating System need a separate license.

    Best regards.

     

    Thursday, August 26, 2010 12:14 AM
  • I was unsure of how WDS deployed, and if the computer that was remotely installed required a separate license.  As you explained, it would require a separate license, but that computer already has Windows XP on it (licensed), so there is no reason to install a new OS where we would have to purchase a license.  In short, we will run the remote computer with our licensed version of Windows XP.  All that computer will be used for is to RDP onto the server- nothing else.  So, XP will work fine.

    The server is currently under the trial period.  We were just waiting to make sure that we could get everything operating as we wanted before purchasing the full version.  We cannot get things running as we wanted, but regardless, we will need server software in order to have multiple people working on it simultaneously.  So, we will be purchasing Server 2008.

    As I stated earlier, we do not intend to break the EULA.  :-)


    Rick
    Thursday, August 26, 2010 1:18 AM
  • The server is currently under the trial period.  We were just waiting to make sure that we could get everything operating as we wanted before purchasing the full version.  We cannot get things running as we wanted, but regardless, we will need server software in order to have multiple people working on it simultaneously.  So, we will be purchasing Server 2008.

    As I stated earlier, we do not intend to break the EULA.  :-)

    Have a look to the different articles about the existing editions so that you can determine the needed edition that allow you to work with the least of costs.

    Best regards.

    Thursday, August 26, 2010 1:30 AM
  • Unfortunately, nothing was actually resolved from what we originally needed to do.  To resolve the DHCP issue we had to remove all relevant services and re-add them, losing all user accounts at the same time, so we almost had to start from scratch.  And, the creating a terminal is apparently not possible with Windows Server, so we are back to just using an XP machine and logging in with RDP, which is exactly what we were trying to change.

    I do appreciate the help that everyone tried to give, but ultimately we just went around in a big circle and have ended up back where we started.

    Rick


    Rick
    • Marked as answer by Brewhaus Thursday, August 26, 2010 2:14 PM
    Thursday, August 26, 2010 2:14 PM
  • The solution for this issues is go to the Advance TCP/IP Setting, DNS Tab and there,register the DNS suffixes. After that from command prompt run "ipconfig -flushdns" and "ipconfig -registerdns". Then go again to Advance TCP/IP Setting and remove DNS suffixes. This allow you to authorize the DHCP from Active Directory.
    Over Windows Server 2008 R2 X64
    This fix work for me.

    Good Luck!!

    Friday, May 11, 2012 6:50 PM