Saturday, November 10, 2007
Phone software: http://www.microsoft.com/downloads/details.aspx?familyid=EEB1B339-DF7E-486F-A47A-23D7ED8BE6FD&displaylang=en
Update Server software: http://www.microsoft.com/downloads/details.aspx?familyid=889c542e-8b09-46c2-bd86-671c21668830&displaylang=en
The steps below outline how to configure the phone for internal communications only.
- One Tanjay/LG/Nortel/Polycom handset
- One Microsoft Office Communications Server 2007 Standard Edition server
- At least one SIP enabled domain user
- An exported copy of the Domain or Enterprise root Certificate Authority certificate available on a network share
- A network segment allowing DHCP client address leases
- DNS properly configured to allow Office Communicator 2007 automatic sign-on
By the way, if you're trying to use the USB port on the back of the phone to upload a certificate I couldn't get this to work. Please post your comments if you've found a way other than described in this article!
- Connect the phone's power and network cables
- Power on the phone and tap the exit button on the screen
- Double-tap on the My device icon
- Scroll down to Control Panel and double tap to open
- Double tap the Owner information
- Tap the Network ID tab
- The dialog box will require you to enter a username, password, and domain. You may need to tap and hold the title bar to move the window around since the virtual keyboard consumes most of the screen. Use a valid domain account with permissions to the file share where you exported your root certificate. Tap the OK button when you're done.
- Click the "X" button to close the window
- You should see a mini windows explorer style interface. Tap the View menu and choose Address bar
- Tap the address bar window and enter the location of your root certificate. For example, \\servername\sharename. Be sure to tap the return key on the keyboard to "confirm" the share entry. If all goes well you will see the files/folders of your server and hopefully your certificate. If you have difficulty with this step you may need to return to the Owner information screen to re-validate the credentials used. I had to repeat this step several times since the keyboard will obscure the view of what you're typing.
- When you've located your certificate tap and hold to select it from the menu. Tap Copy and navigate to My Documents. Tap and hold to open the context sensitive window again and tap Paste.
- Open Control Panel again and choose Certificates
- Tap the Import button and tap the OK button
- Navigate to My Documents and choose your certificate
- So now you're probably wondering how to get the OCS client running again right? Navigate to the Windows folder and double-tap the domo shortcut
- Enter your credentials and you're done!
Now for my thoughts on the 16-step process...
If I had to provision several hundred of these for a client I would likely loose my mind! Between the goofy full screen keyboard hiding critical text boxes and the system time not being set correctly I wouldn't be able to sleep at night proposing this solution to a client. There are serious holes in the entire Office Communications Server and Communicator documentation relating to infrastructure design, implementation, and supportability.
Perhaps there is a better way? I hope those who know will inform the rest of us because Microsoft's documentation is lacking this fundamental component -again.
An iPod style scroll wheel allows you to quickly navigate your contacts and select/call them with the push of a button.
...now the hard part...getting it to talk to my OCS 2007 server!
Thursday, November 1, 2007
I recently completed the installation of a 2-node file cluster for a client who was using an HP EVA8000 disk system and had great difficulty in getting the quorum resource to be located.
For those of you who encounter similar issues, I found this KB article to be quite helpful: http://support.microsoft.com/kb/886807/en-us
The customer had built the two nodes up and formatted the volumes on both servers which was some what of a pain to get resolved. The end result to fix it was to shut down node 2 and create the cluster on node 1 using the "minimum" setting as described in the above article. I later created a Physical Disk resource and modified the properties of the cluster to use the shared quorum insead of the local one, then removed the local quorum and brought the cluster group online.
Note: I also had to re-format the volume(s) on node 1 before starting the cluster configuration.
I had to shut down node 1 then brought node 2 online and performed a "refresh" of the disk so it would "see" it. I then turned on node 1 and added node 2 to the cluster.
Hope this helps!
Monday, October 22, 2007
1 Edge Server
1 Standard Edition Server
Internal Domain name: contoso.local
External Domain name: contoso.com
serverA = Standard Edition server hosting users and serving as a Director
serverB = Edge server hosting the Access, Web, and A/V roles
firewall1 = ISA Server 2006 used to reverse proxy the Web Components traffic
sip.contoso.com (for the external port 5061 traffic)
ocs.contoso.com (for the port 443 Web Components traffic such as Live Meeting's whiteboard functionality)
meeting.contoso.com (for the port 443 Live Meeting functionality)
serverA.contoso.local (generated by an internal certificate authority such as Microsoft Certificate services and bound to the Standard Edition Server/Director)
NOTE: The above certificate MUST have a subject alternate name of serverA.contoso.com as well (see below for more).
serverB.contoso.local (also generated by the internal CA and bound to the private interface of the Edge server)
192.168.10.100 = serverA.contoso.local
192.168.10.101 = serverB.contoso.local
10.1.1.1 = Access role on serverB.contoso.com
10.1.1.2 = Web Conferencing role on serverB.contoso.com
22.214.171.124 = ISA Server public interface (will be NAT'd to perimeter network)
126.96.36.199 = ISA Server public interface (will be NAT'd to perimeter network)
188.8.131.52 = ISA Server public interface (will be NAT'd to internal network)
10.1.1.100 = ISA perimeter network interface
192.168.10.1 ISA Server private internal network interface
External DNS records:
"A" record for sip.contoso.com pointing to 184.108.40.206
"A" record for meeting.contoso.com pointing to 220.127.116.11
"A" record for ocs.contoso.com pointing to 18.104.22.168
"SRV" record for _sip._tls.contoso.com pointing to sip.contoso.com on port 5061
Internal DNS records:
"A" record for serverA.contoso.local
"A" record for serverB.contoso.local
"SRV" record for _sip._tls.contoso.local pointing to serverA.contoso.local on port 5061
IMPORTANT!! --> "A" record for serverA.contoso.com = 192.168.10.100
The above entry is critical since the ISA server will be performing reverse proxy HTTPS access on the public side with "ocs.contoso.com" and then establishing a new HTTPS connection with "serverA.contoso.local". The issue I ran into is that the ISA server cannot change the domain suffix from .com to .local. The host name only changes on the internal HTTPS request. What makes this VERY difficult to troubleshoot is the fact that the firewall logs show a connection to:
If you look at the ISA alerts or the server's application log you will notice that it complains about the target name being incorrect. It's trying to connect to serverA.contoso.com and not serverA.contoso.local. The end result is an HTTP 500 on the client browser if you test the web component functionality (https://ocs.contoso.com/conf/ext/tshoot.html).
Just remember, you MUST have a subject alternate name with "serverA.contoso.com" for your internal certificate on the standard edition server.
ISA Server firewall rules:
NOTE: Rules have already been set up to NAT traffic from the perimeter network to the Internet.
- Allow OCS_SIP from External (22.214.171.124) to 10.1.1.1 via port 5061
- Allow HTTPS Server from External (126.96.36.199) to 10.1.1.2 <---NOTE this is a non-web server traffic publishing rule
- A web publishing rule for HTTPS traffic to "ocs.contoso.local" on 188.8.131.52 going to serverA.contoso.com which is actually 192.168.10.100