I recently migrated our Fileserver from an extremely old Windows 2003 virtual machine (that at one point was a physical machine) to a Server 2008R2 virtual machine. Everything with the migration went awesome and without a hitch except for the part where Excel 2007 spreadsheets were taking a very long time to open all of a sudden for some users but not for others. The users who were experiencing no issues were on Windows 7, users who were experiencing the issue were on Windows XP.
So, with the help of a consultant we use from time to time, here is the list of tweaks and changes we put together to apply to the Fileserver. After these fixes were in place Windows XP desktops are experiencing no issues opening spreadsheets, and the consensus from users seems to indicate performance issues we had in the past with saving and refreshing spreadsheets are greatly improved.
- Install MS KB 2567680
- Install Windows Server 2008R2 SP1
- Disable Windows Firewall
- Disable IPv6 completely inside the Windows registry.
- Disable ‘Network Threat Protection’ inside Symantec Endpoint Protection on this server.
- Install MS hotfix 2194664 (http://support.microsoft.com/kb/2194664)
- Disable TCP Chimney Offload (http://support.microsoft.com/kb/951037)
- Disable SMB 2.0 (http://www.petri.co.il/how-to-disable-smb-2-on-windows-vista-or-server-2008.htm)
All employees use Outlook 2007. I have migrated our Exchange environment from Exchange 2003 to Exchange 2010 probably 3 months ago.
One user’s calendar (we will call him Tom) was not showing Free/Busy information to any other user who had added Tom’s calendar to their Outlook. In addition Tom mentioned that when he tried to edit his own calendar permissions it was throwing errors.
I added the user’s calendar to my Outlook (which is version 2010) and nothing showed up. I then setup an email profile for Tom on my computer and logged in and looked at his calendar permissions. And, there were none. Not even the default permissions, which was pretty awesome. So I added in myself, clicked OK and it came up with the error message saying “Unable to Modify Permissions”. I logged in as Tom through OWA and tried to modify the permissions and the same error occurred.
At this point I did what any good SysAdmin does and break out my Google Fu to see if it can shed any light on this issue, because I have no idea how to get the default permission to show up short of recreating the mailbox and I don’t quite want to go that route yet. Sure enough after about 10 minutes of digging I came across this article (SysAdmin fail, I didn’t save the right link. Crap.) that said one way to recreate the default permission was to add someone as a delegate and then remove.
So I added myself as a delegate to Tom’s mailbox, closed out of Outlook, reopened Outlook and removed myself and then verified on Tom’s calendar that the default permission was now present. I then logged into Outlook as myself and wasn’t able to view his Free/Busy information yet, but I was through OWA. A few hours later Tom’s Free/Busy calendar information was showing in my Outlook and was for other users as well.
Background: I am in the midst of a VMWARE View desktop deployment, and through the process of testing and rolling out have used up one MAK key and am well on my way to a second. I have a KMS Key available to me so I decided to use that instead, and well, it became quite a pain.
I setup a brand new Windows 7 VM called WIN7KMSHOST,with a basic configuration (minus the floppy) with 1 CPU and 1 GB of RAM and joined it to the domain. Disable UAC as well and I then followed the steps in this video, and have outlined them below as well:
- Open up a command prompt with administrator privileges and browse to the C:WindowsSystem32 directory.
- Enter the command: cscript slmgr.vbs /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX where the X’s are your KMS key.
- When that finishes successfully enter the command: cscript slmgr.vbs /dlv and you should see an output similar to the one shown in the video at the 2:09 mark.
- Next step is activation of the KMS host key, to do this run the command: cscript slmgr.vbs /ato
- When that finishes successfully you will see an output similar to the one shown in the video at the 2:50 mark.
- If you have Windows Firewall enabled you will need to go into the settings and allow the Key Management Service through the domain firewall. If you use another firewall, you will need to make sure that Port 1688 is open on the firewall.
- On your primary domain controller, go to DNS, Forward Lookup Zones, YourDomain.com, and then TCP and you should see an entry for _VLMCS with the name of your KMS Host machine. This is shown at the 4:05 mark in the video.
- Final step is to install a KMS Key on the client. If you have previously used a MAK key, or need to setup a KMS key, visit this link. It contains the Windows 7 Client Keys you need to use for whatever version of Windows 7 you are running, along with what to do if you previously used a MAK key.
- Remember, you need to have 25 machines running KMS keys for them to activate on the KMS host for the first time.