Microsoft Excel Documents open very slowly from the network or don’t open at all

A few users reported very slow opening of Excel documents from network shares. The bigger the document, the slower it opened. Sometimes Excel would just crash.

I found some posts that suggested to uninstall security patches, but I’m not very keen on that. I actually immediately suspected the new Office File Validation Add-In because we had some problems with it before. It appeared indeed related to the OFV Add-In.

It seems Microsoft issued a fix and several work arounds for exactly this problem in KB2570623. A patch was released on sept. 13th through KB2553065. We are currently testing the patch.

I’ll list the work arounds here for archive purposes. My preferred method, might the patch not fix the problem, seems to be Method 4:

Workarounds
Method 1:
To be able to have both the protection of the OFV, and typical performance over the network when opening files, upgrade to either Microsoft Excel 2007 or Microsoft Excel 2010.

Method 2:
Copy the file to the local workstation. Open and save it in Excel from the local hard drive. Copy the file back to the network location.

Note: If multiple users are accessing the same file, you must be cautious to collaborate with the other users before you copy the file back to the share so that you do not overwrite the changes that were made by another user. The Shared Workbook feature cannot be used with this workaround.

Method 3:
To use Excel 2003 and avoid the network performance issue, you can disable the Microsoft Office File Validation Add-in for Excel by removing the Excel portion of the OFV. This removes the additional protection of the OFV for Excel while still protecting the other Office applications.

Fix it for me
Microsoft Fix it 50748

Method 4:
To use Excel 2003 and avoid the network performance issue, you can disable the Microsoft Office File Validation Add-In for Excel by using a registry setting. This removes the additional protection of the OFV for Excel while still protecting the other Office applications.

More information about this setting is available here:
http://technet.microsoft.com/en-us/library/gg985445%28office.12%29.aspx

Fix it for me
Microsoft Fix it 50741

Let me fix it myself
You can use the EnableOnLoad registry entry to configure how you want Excel to handle opening workbooks for the OFV. By default, the EnableOnLoad entry is not present in the Windows registry. To add the EnableOnLoad entry to the Windows registry, follow these steps:

Exit Excel.
Click Start, click Run, type regedit, and then click OK.
Locate and then click to select the following registry key:
HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\
After you select the key that is specified in step 3, point to New on the Edit menu, and then click Key.
Type Excel, and then press ENTER.
Select Excel, point to New on the Edit menu, and then click Key.
Type Security, and then press ENTER.
Select Security, point to New on the Edit menu, and then click Key.
Type FileValidation, and then press ENTER.
Select FileValidation, point to New on the Edit menu, and then click DWORD Value.
Type EnableOnLoad, and then press ENTER.
Note: The default value is 0 which disables the validation.
On the File menu, click Exit to quit Registry Editor.

Quick Note: Configure a MPIO VMware iSCSI Software Adapter on vSphere 4.1 with 2 physical nics using Jumbo Frames

esxcfg-vswitch -a vSwitch1
esxcfg-vswitch -m 9000 vSwitch1
esxcfg-vswitch -A iSCSI1 vSwitch1
esxcfg-vswitch -A iSCSI2 vSwitch1
esxcfg-vmknic -a -i 10.1.41.101 -n 255.255.255.0 -m 9000 iSCSI1
esxcfg-vmknic -a -i 10.1.41.111 -n 255.255.255.0 -m 9000 iSCSI2
esxcfg-vswitch -L vmnic2 vSwitch1
esxcfg-vswitch -L vmnic3 vSwitch1
esxcfg-vswitch -p iSCSI1 -N vmnic3 vSwitch1
esxcfg-vswitch -p iSCSI2 -N vmnic2 vSwitch1
esxcfg-swiscsi –e
esxcfg-scsidevs -a | grep “iSCSI Software”
esxcfg-vmknic –l
esxcli swiscsi nic add -n vmk1 -d vmhbaxx
esxcli swiscsi nic add -n vmk2 -d vmhbaxx
esxcli swiscsi nic list -d vmhbaxx

On every iSCSI portgroup, put 1 vmnic as active, the other as unused (standby didn’t work for me).
When config is complete, don’t forget to set a path selection policy on your datastores.

Connect your ESXi 4 host to an HP 4800G stack with a trunk/aggregation link

UPDATE:
Underlying blog post is wrong. I wasn’t fully up to date with the technologies. I would like to remove the post, but will keep it here to prevent others from making the same mistake.

I was enlightened by a very experienced network engineer. He explained to me how teaming/bonding/trunking works on the Layer2 and Layer3 level. On the L2 level it boils down to communication between 2 MAC addresses. You can easily trunk between 2 switches because each switch has 1 MAC address. It becomes more difficult when you want to trunk between a switch and multiple NIC’s (e.g. an ESX(i) server). Because every NIC has it’s own MAC address, the L2 type of trunking, won’t work any more. This is where the virtual switch come in to the picture.
The physical NIC’s of the ESX(i) host (vmnic’s) are connected to the vSwitch. Then you set the vSwitch to do the ‘trunking’ (Load balancing policy IP Hash). Now, on the physical switch, you need no configuration.

For the same reasons you cannot connect a bond to 2 separate switches. A bond pairs 2 or more NIC’s on the OS level. On the switch level you’ll have to create a trunk/aggregation link, hence this will never work with 2 separate switches. The obvious solution to this is to stack your switches (SMLT), thus making it 1 logical switch (with 1 MAC address).

I want to note that you can do LACP trunking with some blade enclosures. They have a build-in switch, thus giving it one MAC address externally. On the inside of the blade enclosure, some type of bonding is done.

END OF UPDATE.

A few quick notes to successfully connect your ESXi 4 host to a nHP 4800G switch or stack using a trunk/aggregation interface. First thing to note is that I don’t use the word LACP. That’s because ESXi doesn’t support it. Read up here and here. That said, I come to the following notes:

1. Don’t use LACP. No link-aggregation mode dynamic.
2. Don’t use a hybrid port link-type. You can only use a static trunk type so use link-type trunk
3. Set the pvid vlan to the management VLAN.
4. Set the Management Network on the vSwitch to VLAN 4095 (All)
5. Set the  vSwitch Load Balancing policy to Route based on IP hash (you probably already knew this)
6. Through an SSH connection (or on the console), use the command

   vim-cmd hostsvc/net/vswitch_setpolicy --nicteaming-policy=loadbalance_ip vSwitch0

   to set the policy again.

7. Through an SSH connection (or on the console), use the command

   vim-cmd hostsvc/net/portgroup_set --nicteaming-policy=loadbalance_ip vSwitch0 "Management Network"

   to set the policy on the Management Network port group.

8. First set all needed config to the switch port, then apply the aggregation config. So add the command ” port link-aggregation group <group number>” as the final command to all ports.

For me, these 2 vim-cmd commands were needed to get things working. That was probably because I was troubleshooting and used a lot of config settings so that might have confused the vSwitch in some way. The commands come from this KB article.

Here are the config examples:

interface Bridge-Aggregation1
 description <ESXi host>
 port link-type trunk
 port trunk permit vlan 10 20 30 40 100 300
 port trunk pvid vlan 100

interface GigabitEthernet1/0/1
 description <ESXi host>
 port link-type trunk
 port trunk permit vlan 10 20 30 40 100 300
 port trunk pvid vlan 100
 broadcast-suppression pps 3000
 undo jumboframe enable
 port link-aggregation group 1

Good luck!

Moving your Key Management Server (KMS) to another server or host

Do you know which server hosts your KMS? By default it’s the first Windows 2008 Server server that you introduced into your domain infrastructure. But do you know which server that was? Because of the confusion that existed when Microsoft introduced their KMS licensing, you probably have no problem activating your Windows servers. Initially everybody just used their KMS key as a VLK and put it on every server making every server a KMS host in the process. It’s now been 3 years since the system was introduced, so I presume you admins all got this part of you infra in order and you know the slmgr.vbs utility =) Otherwise, read this and this first.

These are the slmgr.vbs parameters available on a KMS client:

These are the parameters available on a KMS server/host:

Now, I wanted to move my KMS server to another server. It still ran on the first Windows 2008 Server server and it needs to move to a dedicated (license) server. I also wanted to (still) use a DNS SRV record to let other servers find the KMS host through DNS. I didn’t want to change this ever again, so I created a CNAME record named KMS and pointed that to the new KMS host. These are the steps you need to do (in an elevated prompt mostly):

• (DNS) Create a CNAME record named KMS and point it to your new KMS host.

• (OLD KMS) slmgr -cdns => Disable DNS publishing
• (OLD KMS) slmgr -upk => Uninstall Product Key

• (OLD KMS) slmgr -cpky =>Clear Product Key from registry

• (NEW KMS) slmgr -upk => Uninstall product key
• (NEW KMS) slmgr -ipk <YOUR KMS KEY> => Install KMS key. This will  make this server the new KMS host.

• (NEW KMS) slmgr -ato => Activate Windows. This will activate the new KMS host.

• (NEW KMS) slmgr -sdns => Enable DNS publishing.

• (NEW KMS) slmgr -dlv => Display license info. Check if everything is OK.

• (NEW KMS) slmgr -xpr => Expiration date. The server should be permanently licensed.

• (NEW KMS) reboot
• (OLD KMS) reboot
• (OLD KMS) slmgr -ipk <KMS Client Key for this Windows Edition>. All keys are publicly available and can be found here. You might get an activation error when you rebooted. Just put in the correct KMS Client Product Key.

• (DNS) Check if a new SRV record named _VLMCS is created in DNS that points to you new KMS host. You can find it in <server name>\Forward Lookup Zones\<domain name>\_tcp\. Change the record to point to your CNAME record (kms.<your DNS Domain name>). Delete the SRV record that points to you old KMS host. To speed things up, do this on every DNS server manually.

• (OLD KMS) ipconfig/flushdns => Flush the local DNS cache.
• (OLD KMS) nbtstat -RR => Flush the local NETBIOS cache.
• (OLD KMS) slmgr -ato => Activate Windows. This will activate this Windows client against the new KMS host.

• (OLD KMS) slmgr -dlv => Review the license details.

• (OTHER WINDOWS SERVERS) repeat the previous 4 steps.

When you receive an error 0xC004F038 saying ‘The returned count from your Key Management Service is insufficient’ you can find more info here.

You’ll just have to activate more Windows servers against this KMS host and the error will resolve itself. A KMS hosts will not work for less then 5 servers to prevent ‘pirated’ use in home/lab networks.

If you have servers that are not in your domain and you want to activate them, the SRV record in DNS might not be found. Use the command ‘slmgr -skms <kms server FQDN>:1688’ to force the KMS host address on that server.