1. From the command prompt on the source DHCP server run the following command:
netsh dhcp server export c:\dhcp.dat all
2. Copy the “dhcp.dat” file to the new, or destination, DHCP server and run the following command:
netsh dhcp server import c:\dhcp.dat all
While running the export command, the DHCP service will be temporarily stopped and won’t respond to DHCP requests. Also, the import will fail if there are any existing DHCP scopes that overlap with the original DHCP servers configuration.
In working with XenServer over the past couple of months, I have found that information is harder to come by than it is with VMware. We are only using XenServer for one customer and they are using the free version so support is not an option. Up until last week, I had no need to get into the CLI of Xen much. It’s pretty easy to configure via XenCenter and our setup is pretty simple. However, the other day, our monitoring software detected an issue where the network interfaces on one of the monitored VMs was logging a high number of discards. One of the peculiar things was that the discards were the exactly the same for Tx and Rx. After some research, I decided that it would be a good idea to run off all the offloading features in XenServer. XenServer sees network interfaces in two forms: physical interfaces (pifs) and virtual interfaces (vifs). Pifs are the actual connections to the server. Vifs are the NIC interfaces of the VMs. Naturally, turning off all of this can only be done via the XenServer CLI. So, part one of the gotcha…here is a set of scripts that can help in manipulating network interfaces in Xenserver
Script to turn off all offloading techniques off on all vifs and pifs: [more]
====================================================
#!/bin/bash
if_modes="rx tx sg tso ufo gso"
if [[ "$1" == "--local" || "$1" == "-l" ]]; then
echo -n "disabling checksum offloading for local devices... "
for iface in $(ifconfig | awk '$0 ~ /Ethernet/ { print $1 }'); do
for if_mode in ${if_modes}; do
ethtool -K $iface $if_mode off 2>/dev/null
done
done
echo "done."
else
echo -n "disabling checksum offloading in xapi settings... "
for VIF in $(xe vif-list --minimal | sed -e 's/,/ /g')
do
###xe vif-param-clear uuid=$VIF param-name=other-config
for if_mode in ${if_modes}; do
xe vif-param-set uuid=$VIF other-config:ethtool-${if_mode}="off"
done
done
for PIF in $(xe pif-list --minimal | sed -e 's/,/ /g')
do
###xe pif-param-clear uuid=$PIF param-name=other-config
for if_mode in ${if_modes}; do
xe pif-param-set uuid=$PIF other-config:ethtool-${if_mode}="off"
done
done
echo "done."
fi
====================================================
- create text script file (turnOffloadingOff) using VI
- Change perms to make it a script
chmod 777 turnOffloadingOff
- Run script
./turnOffloadingOff
Other Useful XenServer Commands
- determine uuids of physical interfaces on XenServer
xe pif-list host-name-label=<hostname>
- determine parameters of the specific pif given the uuid
xe pif-param-list uuid=<uuid of pif>
- determine uuids of virtual interfaces of VMs on Xenserver
xe vif-list
- determine parameters of the specific vif given the uuid
xe vif-param-list uuid=<uuid>
- new VMs created since the script was executed will NOT have the same vif other-config settings disabled
xe vif-param-set uuid=<uuid of vif> other-config: ethtool-gso=”off”
xe vif-param-set uuid=<uuid of vif> other-config: ethtool-ufo=”off”
xe vif-param-set uuid=<uuid of vif> other-config: ethtool-tso=”off”
xe vif-param-set uuid=<uuid of vif> other-config: ethtool-sg=”off”
xe vif-param-set uuid=<uuid of vif> other-config: ethtool-tx=”off”
xe vif-param-set uuid=<uuid of vif> other-config: ethtool-rx=”off”
So on to part two of this post…this didn’t fix the problem. After a ton of additional troubleshooting, I determined that this behavior is due to the Citrix Paravirtual NIC driver. The issue goes away if you uninstall XenTools and the PV driver isn’t used. On Windows 2008 and Windows Vista/7 VMs, the PV Ethernet driver reports discards to the OS. In Windows 2003 and XP, it does not. Keep in mind the discards could be broadcast packets not intended for the VM or misc DOM0 traffic. In any case, it doesn’t make much sense, but there isn’t actually anything wrong with the VM. I ended up removing the monitoring of the VMs NIC interfaces because I did want to use the PV Ethernet driver.
We recently encountered some machines running Windows Embedded with the Write Filter enabled that were losing their trust relationship with an Active Directory domain due to mismatched passwords associated with computer accounts. [more]
Cause: After 30 days (default), machine account password expires. The password is updated on the machine as well as in AD. At some point, the machine is rebooted. Since the machine is running in Read Only mode (write filter enabled), the password associated with the computer account is reverted back to the password that is stored with the image on the machine. Since that password does not match the one stored in AD (the updated password), the machine can no longer communicate with the DC and the trust is broken.
Resolution: Windows Embedded Standard (from XP forward) has the ability to retain specific registry keys across reboots. It is called the Registry Filter service (Regfilter), and it works like this: determine what you want to retain, and configure it in a specific area of the registry. The service will monitor the specified key for changes, if there are any it'll both keep them in memory and write them in a specific way to c:\regfdata. From then on, any system call to read or write to that key will instead be reading from and writing to the key in memory and in c:\regfdata. When using a prebuilt HP image, keys for the Terminal Services Client Access License (TSCAL) and Domain Secret Key (key that holds the secret password for the issue above) are already added to the regfilter registry key. This process didn’t seem to be working with the current HP image we were using. However, the most current image on HP’s site did work.
The other day I tried to take an old laptop from one of our auditors to use on an audit. When the auditor got his new laptop he migrated his entire system partition to the new machine, then renamed the machine on the domain. This had the effect of updating his domain machine account to the new machine, and essentially killing his old machine's ability to logon to the domain. This might not be a huge deal, except the old machine was set up to use RSA.
From my understanding, RSA kills access to local accounts. So, without being able to login with local accounts or domain accounts (since the machine account was essentially removed), the old laptop was pretty useless. To work around the authentication issue I had to have the previous owner login to the machine offline (i.e., with it unplugged from the network so cached credentials would be used). I was then able to enroll one of my fingerprints under the auditor's account to allow me to use his old laptop offline for a few days before doing a full cleanup and rejoining the domain.
So, the lesson to be learned is, if you are going to migrate an old system to a new system using the same old domain machine account, please go back after the process and cleanup the old machine (remove RSA, rejoin the domain, reinstall RSA) so it will be useful to the next person.
One of our customers was having problems connecting Outlook to exchange accounts hosted with Microsoft through their Office365 program. The machines in the domain running Windows XP with Office 2007 had no problem connecting, but none of the Windows 7 machines with Office 2010 were able to connect. Since the email accounts were hosted at Microsoft, Outlook was using port 80 web traffic to establish a connection. After exempting the source IP of the test machine from filtering in the Barracuda, the connection immediately worked. This proved that something was not working correctly inside the Barracuda.
The domain outlook.com was whitelisted prior to these changes. After talking to Barracuda tech support, they found several IP addresses that Outlook was trying to contact. They suggested adding those IP addresses to the list of IP addresses that bypass the Barracuda, which is the proxy server, and opening port 80 for those IP addresses on the firewall. We made the suggested changes and it worked correctly. The Barracuda engineering department found that the traffic to outlook.com was being redirected to live.com, and therefore being dropped by the Barracuda. Barracuda suggested we add an expression to the Barracuda to allow port 443 traffic to live.com, but they later said we would probably have to whitelist live.com for this to work properly. We chose to just leave port 80 open to those IP address on the firewall and have clients bypass the proxy for those addresses.
When troubleshooting issues that might be related to the Barracuda, it is often helpful to temporarily exempt the source IP of the machine on which you are working. When the Barracuda is in Forward Proxy mode, this can be done by going to Advanced > Proxy. Add the IP to the Source IP group under the Proxy Authentication Exemptions.
We recently became aware of a problem with Exchange 2010 users being unable to set their out of office settings. With their legacy Exchange 2003 mailboxes, they could set out of office.
When trying to set out of office within Outlook, users would get an error message that the Exchange server could not be contacted. Performing the “Test e-mail autoconfiguration” kept failing to connect to the server with HTTP status code 401 Unauthorized. It was also noted that OWA would not allow logins because the login credentials would not work for anyone.
After trying to troubleshoot permission problems within IIS of the mail server, I eventually came across this thread:[more] http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/36662e7c-8c4a-44dc-85d9-eb7fab1d8b49/
I ran powershell as an administrator on the server, and typed in the following:
It appears that this command re-imports many IIS modules. In the article, it has a –restart at the end, but I left it off to prevent the server from rebooting. It was not necessary in my case in order to resolve all of the issues with OWA/OOF/Autoconfiguration.
For those who really like to tinker, iOS5 for the iPhone introduced the ability to change the default vibration pattern for each address book contact. Here are the steps:
One of our customers has a point-to-point wireless connection, which started failing with an error that indicated problems with radio interference. I ran the utility to check for busy radio channels, but it did not indicate any problems. (Many channels came back as completely unused.) I eventually reduced the transmit power of the root-bridge radio, which caused the connection to come back up.
In retrospect, the issue was likely caused by a reflection that caused a second radio signal out of phase with the original signal. This reduced or eliminated the signal at the antenna.
You assume, that both Microsoft and Lenovo will create a restore point before applying updates to your computer. I did… and it cost me dearly! I had to rebuild my machine from scratch! Restore points require disk storage, and there is a screen (see below) where the amount of the disk to be used for restore points is specified. In my case the amount was set to “0” (zero), and then when the Lenovo updater tries to create a restore point, it failed. There was no warning that it failed! [more]
An information security audit customer was using Group Policy to disable USB mass storage devices by setting the appropriate registry key from a value of 3 to 4. They verified the registry values were what they expected and moved on to other things.
After I arrived onsite and spot checked the USB restrictions on some of these workstations none of them prevented the use of my flash drive. They scratched their heads and checked the registry key and it had been changed back to a 3. If they forced a GPO update, the key was changed back to a 4 and USB mass storage devices were restricted from then on.
What was happening was these systems had never had a USB mass storage device attached. The first time one is connected, the system performs the initial installation steps, one of which sets this key to a 3 even if it was set to a 4. After reapplying the GPO, the restriction finally took effect for good.