1. SSH to the host.
2. “Su –“ to root.
3. Issue the following commands:
a. esxcfg-auth --enablead --addomain=yourdomain.local --addc=domaincontroller.yourdomain.local
b. useradd ad account name
c. esxcfg-firewall -q activeDirectorKerberos
4. Verify by logging in as yourself.
1. Log in to the Virtual Infrastructure Client (VIC).
2. Highlight an ESX 4 host and select the configuration tab and “Time Configuration”.
3. Check the box to enable the NTP client (disregard any error as this is due to the firewall be reconfigured) and select “Options”.
4. On the NTP Daemon Options screen ensure the service is set to start automatically.
5. Select NTP settings and remove the localhost address (127.127.0.1).
6. Add the following servers to the list and check the box to restart the NTP service.
7. The ntp.conf file will now look like the below:
Configure ESX 3.5 Hosts to sync with Internet Time Servers
ESX 3.5 Hosts
1. Log in to the host.
2. “Su –“ to root.
3. Type the following command: “esxcfg-firewall --enableService ntpClient”.
4. Type the following command: “service ntpd restart”.
5. Type the following command: “chkconfig --level 345 ntpd on”.
6. Edit the ntp.conf file (vi /etc/ntp.conf).
7. Make the following changes to the file (Insert the pound sign to comment out a line):
# Prohibit general access to this service.
#restrict default ignore
# Permit all access over the loopback interface. This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1
# -- CLIENT NETWORK -------
# Permit systems on this network to synchronize with this
# time service. Do not permit those systems to modify the
# configuration of this service. Also, do not use those
# systems as peers for synchronization.
# restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap
# --- OUR TIMESERVERS -----
# or remove the default restrict line
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
# restrict mytrustedtimeserverip mask 255.255.255.255 nomodify notrap noquery
# server mytrustedtimeserverip
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 3.us.pool.ntp.org
# --- NTP MULTICASTCLIENT ---
#multicastclient # listen on default 224.0.1.1
# restrict 224.0.1.1 mask 255.255.255.255 notrust nomodify notrap
# restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap
# --- GENERAL CONFIGURATION ---
#
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
#server 127.127.1.0 # local clock
#fudge 127.127.1.0 stratum 10
#
# Drift file. Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /var/lib/ntp/drift
broadcastdelay 0.008
#
# Authentication delay. If you use, or plan to use someday, the
# authentication facility you should make the programs in the auth_stuff
# directory and figure out what this number should be on your machine.
#
#authenticate yes
#
# Keys file. If you want to diddle your server at run time, make a
# keys file (mode 600 for sure) and define the key number to be
# used for making requests.
#
# PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
# systems might be able to reset your clock at will. Note also that
# ntpd is started with a -A flag, disabling authentication, that
# will have to be removed as well.
#
#keys /etc/ntp/keys
8. Edit the /etc/ntp/step-tickers file by issuing the following command: “vi /etc/ntp/step-tickers”.
9. Add the same servers used in the ntp.conf file.
10. File should like the following:
Every now and then you may need to get the World Wide Name (WWN) from a putty session on ESX. The command is pretty straight forward.
esxcfg-mpath -a
This will return the vmhba WWNs and you can start zoning!
Every now and then I have challenges getting a host (Windows and ESX) to register in Navisphere by name. Typically this can be attributed to multihomed (multiple NICs) hosts causing the issue. Pretty simple fix:
Windows Servers:
1.) Stop the Navisphere Agent Service.
2.) Drill down to C:\Program Files\EMC\Navisphere Agent\
3.) Create a text file called agentID.txt (case sensitive). Should look as follows:
Line 1: Fully qualified host name.
Line 2: IP address that you want the Naviagent to use.
Example:
servername.mydomain.local
192.168.12.123
4.) Start the Navisphere Agent service.
5.) Login to Navisphere and do an "Update Now". Your Windows host should now self register by hostname.
ESX Servers:
1.) Stop the naviagent service.
2.) Create the agentID.txt file(same as above) in /root.
3.) Delete the HostIdFile.txt in /var/log.
4.) Start the naviagent service.
5.) Check the new HostIdFile.txt in /var/log and verify that it is using the proper IP address.
6.) Log into Navisphere and do an "Update Now". The ESX host should self register by host name.
NOTE: Navisphere can take some time to update so be patient.
Last week I had to convert a rather large File/Print server from a physical box to a virtual box. No doubt most will say that P2V is the only way to go and I would be hard pressed to disagree. However, given the amount of data needing to be moved, upgrades I wanted to perform (Server 2003 to Server 2003 R2), and reclamation of space I chose to start with a fresh install. Thus I needed a solution that would allow me to move the shares with both share level and NTFS permissions intact. As we are a 24 hour shop down time is hard to come by so the process needed to be as transparent to the user as possible. Lastly, it needed to be free.
In walk Robocopy. If you have never used this tool you need to check it out. It's available as a part of the Windows Server 2003 Resource Kit . If your comfortable with the command line you should have no problem diving right in. For those of you that are a bit more timid, here's a good resource for the different switches available. Of course, there is also a GUI available.
I started the process by building a bare bones virtual machine (we are a VMware shop). I installed server 2003 R2, patched it up, and then installed the following services:
Once everything was up and stable I started to add the additional hard disks I would need to mirror the data from the source server. It's important to note that the drive letters you assign must match the drive letters on the source file server. In this case mine looks as follows:
Source Drive Letters: C - E - H
Target Drive Letters: C - E - H
The drive lettering is like this because I eliminated the A, F, and G drives. No need for a floppy on a VM(A) and with drives F and G I moved the data to drives E and H. Two more steps to perform before we start copying data. We need to export the following registry key from the source server and import it to the destination server:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
Microsoft has a good knowledge base article on saving and restoring existing Windows shares. Next, if you have printers that need to be migrated, grab the Windows Print Migrator (v3.1). Once this has been completed your ready to start moving data. I setup a simple batch file that would copy all the data from the source to the target sequentially. It looked similar to the following:
robocopy "source drive letter\source folder 1" "file://target_server/drive%20admin%20share/source%20folder%201" /COPYALL /MIR
robocopy "source drive letter\source folder 2" "file://target%20server/drive%20admin%20share/source%20folder%202" /COPYALL /MIR
Should look like this: robocopy "e:\test" "file://target/e$/test" /COPYALL /MIR
So what does this do? The /COPYALL switch copies data, attributes, timestamps, security, ownership info, and auditing info. The /MIR switch mirrors the directory tree (purging directories if necessary) and copies all subdirectories (including empty ones). The first time you run this command it will take some time for the data to be moved as it has to copy evrything. Once it has completed it's first run, subsequent runs of these commands will only copy over new and changed data.
I ran this script daily for a few days. Once I was ready to cutover, I ran one last synch, shutdown the source server, and deleted it's account from Active Directory. I then changed the IP address of the new file/print server to that of the old one, renamed it to the same name of the old file/print server and rebooted. Presto, new file server up and running with maybe a 10 minute outage at most.
You need to force a users sessions into Secure Sockets/Transport Layer Security. If your like me, you administer the server and not the actual application. Thus, I am not going to add any code/scripting into the application administrators web pages. The easiest approch I have found to redirecting a web page (without using a script) to port 443 (SSL/TLS) is to create a second site within IIS using the same host header as the site you are wanting to force into SSL/TLS. The steps are as follows:
1. Ensure the primary site is requiring SSL (Image 1).
2. Staying on the primary site, click the web site tab, then click advanced.
3. Here you modify the identity of the web site using host headers. Change the TCP port to anything other than 80 (81 is probably a good choice.).
4. Click OK and OK to accept the new settings.
What you just did was set the site to only accept secure connections (step 1) and changed TCP port 80 to 81. At this point if you were to attempt to access the site using the appropriate URL and port 81 (example: http://localhost:81/) a 403.4 error should be displayed saying https is required. Now we can create the secondary site that will force the SSL redirect.
1. In IIS Manager right-click Web Sites and select New - Web Site.
2. Give the site a descriptive name, such as your site ssl redirect.
3. Right-click the site and select properties.
4. Under Web Site click advanced and add a new host header value. This value must match the Host Header value (yoursite.yourdomain.com) of the site you want redirected to SSL.
5. Select OK.
6. Select the home directory tab.
7. Choose "A redirection to a URL".
8. In the Redirect to: box enter the URL (https://yoursite.yourdomain.com/).
Test.
The site you just created should accept connections on port 80 (unsecure) and redirect the same URL (host header) to the primary site on port 443 (SSL/TLS).