Changing the shared folders location

I recently i had to change the shared folders locations on a OCS R2 installation and it all went smoothly, or at least appeared to :)

Instructions are simple, insert your CD or go to the folder where you have OCS R2 setup and re-run the setup. Click on Prepare Prepare Environment and then Create Enterprise Pool.

You will then face the same questions that you had to fill when you installed it. At some point the wizard will ask for the share folders location and you can change then.
Just make sure on the Reuse Existing Database page, clear the Replace existing database check box or else all your existing data will be lost (not good!).


Looks simple and effective but... it lacks some steps.


First you will need to go over to the Front End IIS and re-map all the virtual directories to the new shares. This one is easy to notice as you get alot of warnings soon enough.

Second, you will find this warning on event viewer:


Event ID 32020 Task Cat. (1055)

Unable to create the Application Host data directory.

Unable to create the directory \\ocs old shares\AppStore\Microsoft.Rtc.Applications.Acd. The network path was not found.
.
Cause: See error message.
Resolution:
Create the directory manually.

Oops... looks like something wasn't changed. :-)

What i had to do to change it was (it might be another solution but i didn't found it):

Go to Start -> Run -> wbemtest
Click connect and type root\cimv2 and then connect.

Now, click on query and type this:

Select * from MSFT_SIPApplicationConfigSetting where Backend="sql_instance"

There will be a few instances returned but only one will have the DataLocation filled. You will have to change that to the new location.

And it's sorted.

Introducing DNS Load Balancing in Communications Server “14”

Keith Hanna published a nice article about DNS Load Balancing in CS 14.

DNS load balancing is introduced in Communications Server “14”. The objective of DNS load balancing is to reduce the need for a Hardware Load Balancer (HLB) for SIP-based load balancing. HLB is both expensive and hard to configure. In addition, HLBs aren’t application-aware; they cannot support “connection draining,” a new feature in Communications Server “14”.

(...)

How Does DNS Load Balancing Work—in Practice?

The client queries DNS to resolve the FQDN of the pool (for example, pool.contoso.com) similar to Office Communications Server 2007 R2. Instead of returning the virtual IP address of the hardware load balancer, the DNS query returns the list of front-end server FQDNs as shown in Table 1. With previous versions of Office Communications Server, this query would return the IP address of the hardware load balancer.
In Communications Server, the DNS query returns the list, {192.168.1.1, 192.168.1.2, 192.168.1.3, 192.168.1.4}, to the client. The order in which these are returned to the client is irrelevant. The client chooses an IP address from the list at random, and then attempt to connect to the front-end server. If the connection fails, the client continues down the list in a random fashion until a successful connection to the pool is achieved or the list is empty.

Client Registration

With previous versions of Office Communications Server, the client would be able to successfully connect to a front-end server. It would then register the client’s SIP URI into the single-shared registration database that is stored on the back-end server running Microsoft SQL Server. However, in Communications Server, each front-end server in a pool has a completely independent registration database. Each user is assigned a predefined registration database (that is, registrar) that they should connect to. This registrar assignment is calculated by a hash value of the user’s SIP URI. Therefore, it is highly likely that a randomly selected front-end server is the incorrect server for the client to connect to. In this example, there is a 75 percent chance the client would randomly contact the wrong server. In other words, there is a 25 percent chance that the correct server was reached on the first attempt. No SIP redirect would be required.

Summary

DNS load balancing is only part of the client connectivity matrix. The internal hashing and distribution of the client registration information is the other part. The two mechanisms work together to determine how a client connects to a pool.
DNS load balancing does not remove the dependency on hardware load balancers completely; however, hardware load balancing is still required for load balancing Web traffic (such as address book services) used in Communications Server. By eliminating the need to load balance SIP traffic by using a hardware load balancer, the complexity of configuring a pool or bank of Edge Servers is significantly reduced.
Keep in mind that the hardware load balancer is still required when operating in a mixed Communications Server and legacy environment (Office Communications Server 2007 R2 or Office Communications Server 2007).

 Full article @ Technet


I think this is a great new feature in MCS, it allow us to deploy older or cheaper HLBs, since all we need HLBs for now is for web traffic, no need for two fancy F5 ($$) just for OCS.

Communications Server '14' new website

The new Wave 14 CS website is now online.
Head over to http://www.microsoft.com/communicationsserver/cs14/ and check it out.

Communications Server ‘14’ Full Disclosure

Jeff Schertz posted on his blog some new features from MCS (wave 14)

Right now I’m down at TechEd 2010 in New Orleans, LA where the keynote address is in progress.  Microsoft has now officially lifted the Non-Disclosure Agreement (NDA) on all features and content which will be coming in the next release of Communications Server, which is still dubbed ‘Microsoft Communication Server 14’.  The ‘14’ refers to the internal Wave 14 codename which has been used since the birth of this iteration of code.

 More at his blog here.