For some reason I cannot ping my domain controller.(It runs on Windows 2008 r2)
Pinged the server ip for the server itself , got the below error
c:\>ping xx.xx.xx.xx
Unable to contact IP driver. General failure.
Tried to ping the loop back ip
c:\>ping 127.0.0.1
Unable to contact IP driver. General failure.
After extensive Googling, here is a solution I found:
It appears the TCP/IP stack may be corrupt.
Logged into the server via admin account , turned off the UAC then
taking the following steps to reinstall and reset TCP/IP heap to its
original state:
1)Run the cmd as administrator (operation requires elevation (Run as administrator).
2)Type netsh int ip reset in the Command Prompt shell, and then press the Enter key.
3)Restart your computer.
Eventually pleasedownload and update the network driver to the
latest version. If you server is VM, then goahead and update you VM
tools.
Showing posts with label domain controller. Show all posts
Showing posts with label domain controller. Show all posts
Wednesday, July 23, 2014
Monday, April 21, 2014
Renaming a Windows Domain the not so hard way
Choosing a name for your domain
is an important decision which will have many technical repercussions
on the topology of your network infrastructure. Still, choosing a domain
name is largely a business decision that is influenced greatly by the
organization structure and needs.
The problem is that there is almost nothing more variable than the business environment and its needs. For example an organization restructuring may mean renaming some sub domains and/or changing their hierarchy, while a change of the company name will defiantly force a domain name change (a frightening prospect for many Windows administrators).
I was put in such a situation where a company that I am working with as an IT consultant had grown from a small design company of 20 employees with the name of Untilled Studios to became a successful group of companies employing 150+ person with the name of Think Arabia. For a while I ignored the problem but their needs have also developed and they started to need an internal SharePoint site with the name of the new organization and sub-sites for the different companies. It became obvious that a domain rename was needed.
I found that the procedure is very simple and can be easily done. Although there is nothing terrifying about it, I strongly suggest that you do as I did and try it in a test environment. I’ve installed the following virtual machines:
Two Domain controllers (DC0 and DC1): One domain controller can do, but I wanted to match the production environment as closely as I can.


One member server and/or one member workstation: Actually I created two of each to see the effect on member machines that were powered off during the procedure and member machines that were powered on. However, it turned out that all four machines I created acted in the same exact way regardless of whether they were on or off while I was renaming the domain


And the key to the procedure is one domain member machine that is not a domain controller to perform almost all steps from. This can be a Windows 7 machine with Remote Server Administration Tool (RSAT) installed, but I prefer to use Windows 2008 R2 server since the rendom utility gets installed automatically as part of “Active Directory Domain Services” role. But make sure not to promote the machine to a domain controller as this machine should not be a domain controller.

Step 0: Create a new DNS zone with the new domain. As new records will start being created in that zone as soon as we perform the rename.


Step 1: From the Control Station run the rendom /list command.
An xml file will be created that lists the current domain information, namely ForestDNSZones, DomainDNSZones and NetBios name.

Step 2: Edit this file to replace all mention of the old domain with the new domain name. In this case I’ve replaced all occurrences of untitled.local with thinkarabia.net and all occurrences UNTITLED with THINKARABIA.

You can verify the new configuration using the rendom /showforest command:

Step 3: Now that we feel more confident, it is time to upload the modified xml to our domain controllers using the command rendom /upload.

Step 4: Is to verify the radiance of the domain controllers using Run rendom /prepare.
Here is where I 1st faced an unexpected issue. In my first attempt, both of my test domain controllers were not prepared, but worked fine after turning off the Windows firewall. When I repeated the procedure, only one of the domain controllers gave an error while the other did not have any issues although the firewall was on. When I did it in production I turned the firewall off on all DC just in case, and it went fine on the first attempt.

Step 5: The grand moment has come when you do the transfer rendom /execute.

All your domain controllers will start to reboot at the same time!!!
Step 6: In order to continue you need to make your control server (the one we have been working with so far) aware of the domain name change. For that you will need to reboot it twice. Otherwise it will continue to use credentials from the old domain and will no longer be able perform changes on the new domain. By the way, all member servers and workstations will need to be rebooted twice to reflect the change, but not yet
Normally at first, all your machines will suggest logging in using the old domain name. No need for alarm, it is just remembering what user name you’ve used last time you have logged in. You simply need to switch user and login with the new domain name.

Step 7: Reflecting the domain name change on your Group Polices.
Group polices still reference the old domain names, and hence we need to fix it.

This is easily performed using the following two commands:
gpfixup /olddns: untitled.local /newdns:thinkarabia.ent
gpfixup /oldnb:UNTITLED /newnb:THINKARABIA

Step 8: Renaming the domain controllers themselves.
Unfortunately they do not get automatically renamed by rebooting twice; you will need to do it using the following commands:
netdom computername dc0.untitled.local /add:dc0.thinkarabia.net
netdom computername dc0.untitled.local /makeprimary:dc0.thinkarabia.net

Restart the domain controller, and repeat for the other domain controller.
Step 9: There is nothing else left to do on the control server except clean up using rendom /clean
And now you have a new name for your domain controller. But you need to reboot all your member machines twice for the change to take effect on all of them. It is a good idea to schedule the reboot before performing the procedure so that it happens automatically afterwards.
Note that this same procedure can be used to change the hierarchy of your sub domain in the forest. For example the sub domain it.servies.rj.com can be renamed to it.rj.com to reflect an organization restructuring.
This info was taken directly from here
The problem is that there is almost nothing more variable than the business environment and its needs. For example an organization restructuring may mean renaming some sub domains and/or changing their hierarchy, while a change of the company name will defiantly force a domain name change (a frightening prospect for many Windows administrators).
I was put in such a situation where a company that I am working with as an IT consultant had grown from a small design company of 20 employees with the name of Untilled Studios to became a successful group of companies employing 150+ person with the name of Think Arabia. For a while I ignored the problem but their needs have also developed and they started to need an internal SharePoint site with the name of the new organization and sub-sites for the different companies. It became obvious that a domain rename was needed.
I found that the procedure is very simple and can be easily done. Although there is nothing terrifying about it, I strongly suggest that you do as I did and try it in a test environment. I’ve installed the following virtual machines:
Two Domain controllers (DC0 and DC1): One domain controller can do, but I wanted to match the production environment as closely as I can.
One member server and/or one member workstation: Actually I created two of each to see the effect on member machines that were powered off during the procedure and member machines that were powered on. However, it turned out that all four machines I created acted in the same exact way regardless of whether they were on or off while I was renaming the domain
And the key to the procedure is one domain member machine that is not a domain controller to perform almost all steps from. This can be a Windows 7 machine with Remote Server Administration Tool (RSAT) installed, but I prefer to use Windows 2008 R2 server since the rendom utility gets installed automatically as part of “Active Directory Domain Services” role. But make sure not to promote the machine to a domain controller as this machine should not be a domain controller.
Step 0: Create a new DNS zone with the new domain. As new records will start being created in that zone as soon as we perform the rename.
Step 1: From the Control Station run the rendom /list command.
An xml file will be created that lists the current domain information, namely ForestDNSZones, DomainDNSZones and NetBios name.
Step 2: Edit this file to replace all mention of the old domain with the new domain name. In this case I’ve replaced all occurrences of untitled.local with thinkarabia.net and all occurrences UNTITLED with THINKARABIA.
You can verify the new configuration using the rendom /showforest command:
Step 3: Now that we feel more confident, it is time to upload the modified xml to our domain controllers using the command rendom /upload.
Step 4: Is to verify the radiance of the domain controllers using Run rendom /prepare.
Here is where I 1st faced an unexpected issue. In my first attempt, both of my test domain controllers were not prepared, but worked fine after turning off the Windows firewall. When I repeated the procedure, only one of the domain controllers gave an error while the other did not have any issues although the firewall was on. When I did it in production I turned the firewall off on all DC just in case, and it went fine on the first attempt.
Step 5: The grand moment has come when you do the transfer rendom /execute.
All your domain controllers will start to reboot at the same time!!!
Step 6: In order to continue you need to make your control server (the one we have been working with so far) aware of the domain name change. For that you will need to reboot it twice. Otherwise it will continue to use credentials from the old domain and will no longer be able perform changes on the new domain. By the way, all member servers and workstations will need to be rebooted twice to reflect the change, but not yet
Normally at first, all your machines will suggest logging in using the old domain name. No need for alarm, it is just remembering what user name you’ve used last time you have logged in. You simply need to switch user and login with the new domain name.
Step 7: Reflecting the domain name change on your Group Polices.
Group polices still reference the old domain names, and hence we need to fix it.
This is easily performed using the following two commands:
gpfixup /olddns: untitled.local /newdns:thinkarabia.ent
gpfixup /oldnb:UNTITLED /newnb:THINKARABIA
Step 8: Renaming the domain controllers themselves.
Unfortunately they do not get automatically renamed by rebooting twice; you will need to do it using the following commands:
netdom computername dc0.untitled.local /add:dc0.thinkarabia.net
netdom computername dc0.untitled.local /makeprimary:dc0.thinkarabia.net
Restart the domain controller, and repeat for the other domain controller.
Step 9: There is nothing else left to do on the control server except clean up using rendom /clean
And now you have a new name for your domain controller. But you need to reboot all your member machines twice for the change to take effect on all of them. It is a good idea to schedule the reboot before performing the procedure so that it happens automatically afterwards.
Note that this same procedure can be used to change the hierarchy of your sub domain in the forest. For example the sub domain it.servies.rj.com can be renamed to it.rj.com to reflect an organization restructuring.
This info was taken directly from here
Friday, February 7, 2014
Simple Exchange 2010 installation
Cut the bull crap. I have been through what seems like endless amounts of tutorials, blogs, and other instructional guides on a simple Exchange 2010 install for a small Windows domain environment(100 total systems/200 AD users). Why so many nonsensical/fluff included in these guides is beyond me.
Here is what worked for me:
Here is what worked for me:
- Pre-reqs:
- Configure a Windows 2008 r2 domain controller and DNS server. (same system is fine)
- Create a domain account that is part of the following groups: <Schema Admins, Domain admins, and Enterprise Admins>
- Load the Exchange 2010 DVD and perform the three separate commands from command line on the DC itself since it also 'extends the AD schema'. Make sure you prepare AD first:
- Log in as a member of the schema admins domain security group. If there is an existing Exchange organization in place, run setup /prepareAD
from the drive containing the Exchange 2010 installation DVD. If there
is no existing Exchange organization in this environment, run setup /prepareAD /OrganizationName:”<the name of your new exchange organization>”. In the example below, the following command is used: setup /prepareAD /OrganizationName:”First Organization”.
- Schema Updates (setup.com /pl, /ps and /p)
- Build a separate Windows 2008 r2 server with all updates for you Exchange server
- Load the Exchange 2010 DVD
- From command line: Install the Exchange pre-reqs:
- Run from this directory of the DVD: install\scripts>ServerManagerCMD -ip Exchange-Typical.xml
- Reboot
- Run the setup.exe file from Exchange DVD and complete installation.
- Make sure you uncheck those two options in IE as was previously mentioned in an earlier post or you will not be able to open the Exchange MMC.
- Then click on Exchange MMC and allow it to complete its initial setup.
- Bingo bango! Finished.
Subscribe to:
Posts (Atom)