thehelpdesk blog

How to use Apple TV with a Cisco 877W Wireless Router

2012-01-18T00:10:00.000-08:00

Overview
Was asked the other day to help out a friend of a friend with their Apple TV and wireless setup, typical can of worms scenario... and it was! They had been having trouble where their Apple TV would often disconnect and/or refuse to connect to a Home Sharing enabled Windows 7 laptop. So after trying the usual stuff without success, I took it off them to set it up at home and have a bit of play. Not knowing anything about Apple TV or Apple Home Sharing prior to this, I thought well perhaps I'll learn something... and I did (semi-painfully).

It's probably worth a quick introduction into how Apple Home Sharing works. Whether you're running iTunes on a Windows or Mac machine.

You install iTunes on your Windows/Mac machine.
Enable Home Sharing and give it your iTunes account details.
Then connect your Apple TV to your wireless.
Enable Home Sharing with the same iTunes account on the Apple TV.
The Apple Bonjour service advertises your iTunes to your local network.

Other than that, it should just work right? Well not really....

In my setup I am using a Cisco 877W router, and there were a few things I had to do to get it work..

Lab Setup

Apple TV 2 setup to connect to a Cisco 877W Wireless router running IOS 12.4.
Windows 7 64-Bit laptop running iTunes version 10.5 with Home Sharing enabled.
Both Laptop and Apple TV are connecting via wireless and are in a single subnet.

Problem
Apple TV refuses to find the Home Sharing enabled laptop... Period.

Before we begin...
There are a lot of different issues that may cause problems with your Apple TV/iTunes setup so please ensure you've got everything setup correctly. Some of the more common solutions to problems I came across were;

Windows Firewall > Allow Bonjour through the right profile (i.e. Home/Work/etc).
Try deauthorising the account on your iTunes machine and re-enabling Home Sharing.
Reset your Apple TV to factory defaults and reconfigure.
AppleTV will not work if your iTunes and AppleTV unit are in different subnets.

Solution
The Bonjour service uses multicast to advertise your Home Sharing enabled device to the local network. In my case the Cisco 877W I was using had a Layer 3 enabled BVI (Bridged Virtual Interface) to which the Wireless Dot11Radio interface was not fowarding multicast packets properly.

First of all, obtain the Multicast groups your wireless adapter is configured for (on Windows open a command prompt and run the below command):

The result will give you an output as per below, we are interested in the multicast address directly after the 224.0.0.252 address 239.255.255.250:

Then we need to enable multicast routing on the router, connect to your router and enter config terminal mode:

Next we will configure IGMP v3 and add the relevant Wireless interface on your router to the correct multicast address group:

Next perform the same config your BVI interface:

Once complete save your changes and confirm both interfaces have been added to the multicast groups using the command sh ip igmp group:

You now need to reload your router and restart iTunes and then attempt to connect to Home Sharing from your Apple TV.

Other commands that I used to troubleshoot with were:
debug ip mpacket - Multicast Packet Debugging
debug ip mroute - Debug Multicast Routing
sh ip mroute - Show IP Multicast Routes

By default the Cisco implementation of a Dot11Radio interface and a BVI interface don't appear to forward multicast packets between each other. Seems odd to me as they're both in the same L2 bridging group..anyway.

But this worked for me, so hopefully it saves someone else an afternoon.

I've uploaded an example config, which has all the relevant parts.

vSphere Auto Deploy Reinstall Issue

2012-01-16T15:48:00.000-08:00

Overview
I had an unrelated issue with the new Auto Deploy tool for vSphere 5.0 in my lab setup so I decided to uninstall Auto Deploy and reinstall. However on attempting the reinstall, I came across the below error 'The service is already registered with the vCenter Server'.

Googling around and browsing the VMware forums got me nowhere, so I decided to do a bit of digging myself. Appears that in some instances (I'm not sure why mine was special..), the Auto Deploy uninstaller does not properly remove the Auto Deploy service from vCenter. It does however remove all the files you need to be able to do this manually, how kind!

Anyway, with a bit of digging, I was able to figure out how to manually remove the service. Fairly straight forward in the end.

You will need the Auto Deploy installer from the vSphere 5 Resource DVD.

Procedure
1. Run the Auto Deploy installer, and get to the point where you receive the error message. Hold it there.
2. Open Windows Explorer and browse to;

C:\Users\username\AppData\Local\Temp\{92EE2449-2EF1-4455-8DEC-2787F4C594B1}
(your folder GUID may vary, just locate vSphere Auto Deploy.msi.

3. Copy vSphere Auto Deploy.msi. to C:\Temp on your vCenter server.
4. Open a command prompt and extract the contents of the vSphere Auto Deploy.msi file using msiexec.

msiexec /a C:\Temp\vSphere Auto Deploy.msi. /qb TARGETDIR=C:\Temp

6. This will extract the below contents.

7. Now open a Command Prompt and navigate to;

C:\Temp\program files\VMware\VMware vSphere Auto Deploy\

8. Run the below command to manually unregister your Auto Deploy service.

autodeploy-register -U -a vcenterip -u username -w password -p 80

9. Then reinstall Auto Deploy.

References
This article was very useful - Troubleshooting vSphere 5 Auto Deploy
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2000988

VMware Multi-core vCPUs

2011-11-10T12:29:00.001-08:00

Overview

Adding more than 4 vCPUs to a Windows Server Standard (or other) Guest VM.

One of the most common frustrations encountered around virtualising Windows 2003/2008 Standard servers is the licensing imposed physical socket limit of 4 processors for the Windows Server Standard OS. Under VMware vCPU’s appear as 1 physical socket to the guest operating system, meaning you can’t assign more than 4 vCPU’s to the guest OS (well, you can but the Windows OS will just ignore the extra 4).

This is particularly common when P2V’ing SQL or heavy workload servers, which may have had 2 (or more)x 4 core CPU’s previously. Under VMware 4.0/4.1 you can create ‘virtual processors’ by adding a variable to the VMX file of the VM. This allows you assign 8x vCPUs to the VM, and then carve those cores up into logical processors by assigning a value of 2,4 or 8 the ‘cpuid.coresPerSocket’ variable.

The end result being a Windows Server Standard 2003/2008 or Linux Guest VM, which can have the following CPU configurations and greater processing power available to the VM;

4x 2 Core Processors (8 cores total)
2x 4 Core Processors (8 cores total)
1x 8 Core Processor (8 cores total)
3x 2 Core Processors (6 cores total)

NOTE - The maximum amount of cores you can assign is still limited to 8 vCPUs, and the VM must be using Virtual Hardware version 7.0.

Process

1. Power off the virtual machine.
2. Right-click on the virtual machine and click Edit Settings.
3. Click Hardware and select CPUs.
4. Choose the number of vCPUs (this will be the total number of cores visible within the Guest OS).
5. Click the Options tab.
6. Click General, in the Advanced options section.
7. Click Configuration Parameters.
8. Include cpuid.coresPerSocket in the Name column.
9. Enter a value (try 2, 4, or 8) in the Value column.

Note: Ensure that the number of vCPUs is divisible by the number of cpuid.coresPerSocket in the virtual machine. That is, when you divide the number of vCPUs by the number of cpuid.coresPerSocket, it must return an integer value.

For example, if your virtual machine is created with 8 vCPUs, coresPerSocket can only be 1, 2, 4, or 8. The virtual machine now appears to the operating system as having multi-core CPUs with the number of cores per CPU given by the value that you provided in step 9.

10. Click OK.
11. Power on the virtual machine. This VMware KB Article provides further clarification.

This feature is available via the GUI in vSphere 5, but for now you can use the Advanced option as per above, or edit the .VMX file directly in 4.x.

Cisco SSLVPN and Java RDP Plugin Issues

2011-06-02T20:28:00.000-07:00

Overview

Cisco ASA 5510 running IOS 8.4 (latest release 03/06/11) with Java enabled RDP Plugin setup as per this Cisco KB Article for remote users connecting to company Terminal Servers through HTTPs. Whenever you accessed the SSLVPN using Firefox or Safari it would throw the below error message and fail to connect.. 'The terminal server disconnected before licence negotiation completed. Possible cause: terminal server could not issue a licence'.(Note - It worked fine in Internet Explorer... like everything else does, yeah I know showing my prejudices here). And, for most people, just using IE would have been a suitable solution. Unfortunately, this wasn't an option. So after an hour of blaming the security settings in Firefox...

We started to point the finger at the Java RDP plugin installed on the ASA, and decided to try a few different options. Sure enough none of the other OpenSource Java RDP plugins from here (http://properjavardp.sourceforge.net/) would install, and threw the next error, 'Error while reading specified file. Entry rdp cannot be imported'. Some Googling around showed that some other people who experienced the same issue managed to resolve it by just manually typing the name 'rdp' into the ASDM so give this a go first, this didn't work for us however. I can only assume, (because we had another ASA running IOS 8.2 that could install these plugins), that this is an incompatibility with IOS 8.4 and the plugins available on the above site.

Solution

After phoning Cisco to advise them of the issue, they then provided a previously undisclosed version of the plugin, which without some kind of FBI level clearance you might not have previously had access to, which solved the problem.

Download the working plugin from here;Cisco SSLVPN Java RDP Plugin

Works with Safari/Chrome/IE and Firefox, on Windows + Mac and most versions of Java.

Shrink a thin provisioned disk in Vmware ESX 4.1

2011-04-20T13:59:00.000-07:00

Overview

If you’re lucky enough to have a thick provisioned disk, you can shrink the disk using Vmware tools from within Windows. However most VM’s in our environment use thin provisioned disks, you can’t use Vmware tools to shrink a thin provisioned disk. This procedure, and no procedure for that matter will allow you to reduce the 'provisioned' size of a thin provisioned disk in vSphere, i.e. the amount of space assigned to disk when it was setup. The below procedure will only shrink the actual amount of space used by a thin provisioned disk VMDK file on the VMFS LUN. You will need a LUN attached to your ESX hosts with a different block size (most organisations use 8MB for VMFS), create one with a 4MB block size. Applies to Vmware ESX 4.1 only (if using 4.0, you don't need a LUN with a different block size).

Procedure

1. View the actual VMDK storage usage of the thin provisioned disks

vSphere Client > Click on the VM > Summary Tab > Resources > Used Storage (this is what we are aiming to reduce).

2. Ensure there are no Snapshots present for the virtual server.

vSphere Client > VM > right-click > Snapshots > Snapshot Manager.

3. Ensure there are no ISO’s or client CD devices mapped to the virtual machine.

vSphere Client > VM > right-click > edit Settings > Ensure CD/DVD is set to ‘Host Device’.
4. Logon to the Virtual Machine via RDP or vSphere console and run Disk Defragment on the volume you are about to resize.

5. Download sdelete (Sysinternals) this will grow the disk to its maximum size (it actually zero’s out free space, which the vMotion will clean up later). This will take quite a while.

Open a command prompt > type ‘sdelete –c D:’ (where D: is your drive letter)

6. IF Server 2008 – Shrink the partition from within Windows.
Right-click on My Computer > Manage > Disk Management > right-click on the volume you wish to shrink > click Shrink > Shrink the volume to required size.

7. IF Server 2003 – You will need to run GParted (or another partition editor) to shrink the partition.

vSphere Client > VM > right-click > edit Settings > CD/DVD Drive > Download and mount the ISO for GParted > Reboot the VM and boot into the GParted environment to shrink your the NTFS partition on your virtual disk.

8. Next we will peform the datastore migration of the virtual disk to the migration LUN XXXLUN. This works via a ‘feature’ of Vmware ESX 4.1, whereby if you copy a thin provisioned disk to a LUN with a different block size, Vmware will shrink the virtual disk allowing you to regain unused space without having to create new virtual disk and copy contents across.

NOTE - Ensure there is enough space on the destination datastore for the virtual disk you are trying to shrink.

vSphere Client > right-click on the VM > perform a Migration > Select Datastore Migration > Select the Advanced option > under Advanced select a new datastore only for the disk you are resizing.

9. Next you must migrate the virtual disk back to a production LUN.

NOTE - Ensure there is enough space on the destination datastore before you begin copying.

vSphere Client > right-click on the VM > perform a Migration > Select Datastore Migration > Select the Advanced option > under Advanced select a new datastore for the disk you have just finished resizing.

11. Ensure the VMDK disk usage has now shrunk (as mentioned before, we don’t look at the size of the allocated size of the disk in vSphere for thin provisioned disks, as this is misleading. The correct place to check how much storage the client is using is below).

vSphere Client > Click on the VM > Summary Tab > Resources > Used Storage > this should now have shrunk to near the size of data on Windows partitions combined.

12. You should now have reduced disk usage for your VM, and the machine will be limited as to how much space it can use again if you shrunk your NTFS partition for your guest OS as well.

Trend IMSS 7.1 Missing Services and no Admin Console Access

2011-03-23T16:05:00.000-07:00

I recently installed Trend Micro’s Interscan Messaging Security Solution 7.1 onto a client’s existing Server 2008 64-Bit + Exchange 2007 Server. The IMSS install said it completed ok however, there were no Trend IMSS Services listed at all and I couldn’t connect to the Admin Console via https://:8445. I approached Trend Micro Support about the problem who suggested I run the below commands via command prompt.

tsmtpd.exe --install-auto IMSSService.exe -install imssps.exe -install imsscmagent.exe -install imssmgr.exe -install 3

This installed all of the services except one, the ‘Trend Micro IMSS Web Console’ service and obviously I still couldn’t connect the Admin Console. Trend advised this was due to Exchange being installed before IMSS, and a removal of Exchange and reinstall of IMSS needed to take place, unfortunately this really wasn't an option.

So with a bit of digging around the executables in the IMSS folder structure, I managed to get the Web Console Service installed by running the below command at a command prompt;

C:\Program Files (x86)\Trend Micro\IMSS\UI\AdminUI\Bin\imssService.bat install

Changed the service to Automatic, started it and everything came alive. Pretty easy fix in the end, and a lot easier than reinstalling Exchange!

Reinstall the SBS 2008 CompanyWeb Website from scratch

2011-03-04T00:45:00.000-08:00

Overview
Something every engineer who has SBS fall within their brief dreads, is one day having to rebuild the Internal Database, Sharepoint, IIS and CompanyWeb components. Due to a recent natural disaster, we had to restore a client's server from backup, which required a new identical server be built and data restored into it from backup. The system state restore process restored the client's data, but broke pretty much every native component on our new SBS server. And, while there were documented procedures for some of the issues, even the SBS repair guide doesn't seem to have a procedure yet (03/07/11) for reinstalling the SBS 2008 CompanyWeb Website. It took a fair bit of trial and error to get it going. So, hopefully this will help someone stuck in the same situation.

This post will cover the below topics required to rebuild the core SBS 2008 Web Components from the ground up, all of which combine to reinstate the CompanyWeb website. However, you can pick and choose which parts might be relevant to your situation;

Removing the Windows Internal Database.

Reinstalling the Windows Internal Database

Reinstall Windows Server Update Services 3.0 SP2.

Reinstall Windows Sharepoint Services 3.0.

Create a new SBS Sharepoint Web Application.

Reinstall the SBS 2008 CompanyWeb Website.

Testing

IMPORTANT - Please ensure you have a backup of your system and proceed with caution. These steps should be used as a reference only, your individual situation may vary. The Windows Internal Database by default contains the WSUS and Sharepoint and Sharepoint Search databases. This procedure assumes there is no data in any of these databases that you wish to keep.

IMPORTANT - Ensure your system is completely patched and up-to-date.

IMPORTANT - Ensure you logon as the Domain Administrator account only for all of the below steps.

Requirements
What you will need...

a. A backup of the server you are trying to repair.
b. Another SBS 2008 Standard/Premium Server with a known good CompanyWeb Website.
c. WSUS 3.0 SP2 x64 installation package.

Procedure
Keep in mind that you can skip any of these steps if they are not required for your situation, in my case the Windows Internal Database wouldn't even start, so we had to start with that. If your WID is working ok and you trust it then skip forward to the 'Reinstall Windows Sharepoint Services 3.0' step.

Step 1 - Remove the Windows Internal Database
The Windows Internal Database is nothing more than a rebadged instance of SQL 2005 Express. So with that in mind, we can treat it like all other instances of SQL Express right?...Well no, but similar :) It doesn't appear in the list of installed programs, so we need to uninstall it manually. First of all we need to remove WSUS and WSS.

a. Remove WSUS > Control Panel > Programs and Features > Windows Server Update Services 3.0 SP2 > Uninstall.
b. Select the checkboxes to remove Database, Log Files, and Update Files.
c. Remove Sharepoint Services > Control Panel > Programs and Features > Windows Sharepoint Services 3.0 > Uninstall.
d. Select Yes to the warnings that appear when removing Sharepoint.
e. Restart the server.
f. Open an elevated Command Prompt (right-click > Run as administrator) > and type;

msiexec /x {BDD79957-5801-4A2D-B09E-852E7FA64D01} CALLERID=ocsetup.exe

f. Click 'Yes' to confirm you want uninstall this product.
g. Check the event log for 'Event ID 11724' which will inform you the Windows Internal Database was removed successfully.
h. Restart the server.

You now have an SBS 2008 Server without Sharepoint, WSUS, and the Internal Database. Scared yet? Well don't be... it's actually quite an easy process to get it to where it should be from here.

Step 2 - Reinstall the Windows Internal Database
The Windows Internal Database for SBS 2008 is installed as part of the WSUS 3.0 and Windows Sharepoint Services 3.0 installations, if you plan on reinstalling these anyway (which I suspect most people will) proceed to Step 3 - Reinstall Windows Server Update Services 3.0 SP2. However for the purpose of this demonstation and to further demystify the Windows Internal Database we will install it manually in this step.

a. Open an elevated command prompt (right-click Run as administrator) and type the below;

ServerManagerCmd.exe -install Windows-Internal-DB

b. Open Services, and confirm there is now a 'Windows Internal Database (MICROSOFT ##SSEE)' Service listed.
c. Change the service startup type to Automatic.
d. Restart the server.

Step 3 - Reinstall Windows Server Update Services 3.0 SP2
a. Download WSUS 3.0 SP2 x64 from here and right-click > Run as administrator.
b. Select the defaults or customise your installation. A detailed guide on how to setup WSUS can be found here.

Step 4 - Reinstall Windows Sharepoint Services 3.0
NOTE - If you have skipped forward to this step, ensure you remove Sharepoint first using Programs and Features > Windows Sharepoint Services > Uninstall.

a. Open DNS Management > Administrative Tools > DNS > Forward Lookup Zones > Ensure there is a 'CompanyWeb' Alias (CNAME) listed and that it maps to your server, if not create this now.
b. Open IIS > Administrative Tools > Internet Information Services IIS Manager > Sites > Ensure the SBS Sharepoint and Sharepoint Central Administration websites are not present, if they are > right-click and Remove.
c. Open Registry Editor, navigate to >

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\VssAccessControl\

d. Find the entry named: NT Authority\NETWORK SERVICE, and then, if needed, change the value from 0x0 to 0x1.
e. Reinstall Sharepoint > Browse to > C:\Program Files\Windows Small Business Server\Bin\CMPNENTS\WSS.
f. Right-click Setup.exe > Run as administrator. Select the option to Run the Sharepoint Products and Technologies Configuration Wizard.
g. When the wizard completes, restart the server.
h. Open the Sharepoint Central Administrator Console > Administrative Tools > Sharepoint 3.0 Central Adminstration > Open Application Management > select Remove Sharepoint from IIS Website > ensure SharePoint - 80 (Default) is selected in the IIS Website and zone to remove option > Select Yes to Delete the IIS Web sites and > Click OK.
i. Go back to Application Management Tab > Select Delete Web Application > in the Web Application: drop down box, ensure the Sharepoint - 80 site is select (by default this will be http://server/, drop down and select 'Change Web Application to be sure).
j. Select Yes in the option to 'Delete content databases' and Yes to 'Delete IIS Web Sites' > click 'Delete'.
k. From within 'Application Management' select > View Application List > Ensure the 'Sharepoint - 80' Website no longer exists and only the 'Sharepoint Central Administration' Site remains.
g. Open IIS > Sites > And start the Default Website.
h. Update the machine using Windows Update > Ensure you check the option to 'Check online for Updates'.

Step 5 - Recreate the SBS Sharepoint Site and Application Pool in IIS
a. Open the Sharepoint Central Administration Console > Administrative Tools > Sharepoint 3.0 Central Administration.
b. Open the Application Management Tab > select Create or extend Web Application > select Create a new Web application.
c. Create a new IIS web site > description: SBS Sharepoint.
d. Port: 80
e. Host Header: Companyweb
f. Path: C:\Program Files\Windows Small Business Server\Bin\WebApp\InternalWebSite
g. Authentication provider: NTLM
h. Allow Anonymous: No
i. Use Secure Sockets Layer (SSL): No
j. URL: http://companyweb:80
k. Create new Application Pool: SBS Sharepoint
l. Select a security account for this application pool: Network Service
m. Database Server: \Microsoft##SSEE (leave as default).
n. Database Name: WSS_Content (leave as default).
o. Database Authentication: Windows Authentication (recommended).
p. Select Windows Sharepoint Services Search server:
q. Click 'OK' to proceed and wait while changes are processed, can take some time.
r. Open IIS > click on > then in the right hand Actions column > select Restart.
s. Expand Sites > and press F5 > the Default Website will now likely be stopped and you will have an 'SBS Sharepoint' site listed.
t. Right-click on the SBS Sharepoint site > select Edit Bindings > click on http and 'Edit' > add the Host name 'Companyweb' (without quotes).
u. Right-click on the Default Website > Manage Web Site > Start.

Step 6 - Reinstall the SBS 2008 CompanyWeb Website
a. Connect to another SBS 2008 server that has a known working Companyweb website.
b. Open an elevated Command Prompt (right-click Run as administrator).
c. To export the CompanyWeb website from the known good server, type the below commands.

cd c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN
stsadm –o backup –url http://companyweb –filename C:\backup.bak -overwrite

NOTE - If the source server has a different URL configured for the Companyweb site, you will need to change this in the above command. To check which URL the source server is using open Sharepoint Central Console > Application Management > Web application general settings > and check the 'Web Application: URL' at the top of the page and type it exactly as it appears, i.e. using https and :987 if non-standard. For example, SBS 2008 servers are configured to use https://fqdn:987 for the Companyweb site.

NOTE - For some weird reason, you may have to type the stsadm commands manually.

d. Copy the exported 'backup.bak' to the server you are attempting to repair.
e. This step is important, as it ensures your Sharepoint is patched and up to date > Completely patch the machine using Windows Update > Ensure you select the option to 'Check online for updates from Windows Update'.
e. Once patching is complete > Restart the server.
f. Open an elevated command prompt on the destination server and type the below (on separate lines).

cd c:\program files\common files\microsoft shared\web server extensions\12\bin
stsadm -o restore -url http://companyweb -filename c:\backup.bak -overwrite

NOTE - If you receive the 'Your backup is from a different version of Windows Sharepoint etc...' error you will need to go back and update the server using Windows Update and ensure it is completely up to date. Ensure you use 'Check online for udpates from Windows Update'. Restores can only be done to the same of newer versions of Sharepoint than the source server had installed.

g. Next you need to set the correct admin rights on the new CompanyWeb site.

cd c:\program files\common files\microsoft shared\web server extensions\12\bin
stsadm –o siteowner –url http://companyweb –ownerlogin YOURDOMAIN\Administrator

h. Login to CompanyWeb as the Administrator > open your Internet browser > http://companyweb > browse to > Site Settings > People and Groups > Delete the Administrator Account from the server you copied the CW template from.
i. Add the Domain Users group with Design rights.
j. Open IIS Manager again > Configure an SSL Binding on port 987 for the SBS Sharepoint Website using your companies certificate.

Step 7 - Testing
a. Check the ‘Site Collection List’ and ensure all settings are ok.
b. Browse to http://companyweb and ensure access is ok for Administrators and Domain Users.
c. Access Remote Web Workplace and connect to Company Site, this ensure the https://companyweb:987 binding is also working properly.