The Adoption Reporting Tool enables administrators to more easily measure both usage and adoption of Microsoft Office Communications Server 2007 R2 in their enterprise.
More info about it here.
The Adoption Reporting Tool enables administrators to more easily measure both usage and adoption of Microsoft Office Communications Server 2007 R2 in their enterprise.
Issues that this hotfix package fixes
- Provides home screen support for new home screens in Windows Mobile 6.5+ phones.
- Provides integration within the phone dialer for Windows Mobile 6.5+ phones.
- Enables Communicator Mobile 2007 R2 to recognize when the phone is roaming and by default prevents Communicator Mobile 2007 R2 from signing in to roaming networks.
- Provides additional support for joining conference calls from a Windows Mobile appointment. To do this, press Menu, and then press Join Conference.
- Lets users log on by using a user name in the user@example.com format, in addition to the domain\user format.
- Enables the functionality by which callbacks are now automatically accepted when the user uses the Call via Work option.
- Resolves the problem in which the Microsoft Installer (.msi) installation fails on a Windows XP Service Pack 3 (SP3)-based computer. In this situation, users should install Communicator Mobile 2007 R2 by using a (.cab) installation.
- Fixes the problem in which AT&T FUZE devices that are set for a High-Speed Downlink Packet Access (HSDPA) connection cannot handle voice and data at the same time. In this situation, calls that use the Call via Work option fail unless the device is reverted to 3rd Generation (3G) by disabling HSDPA.
Unable to create the Application Host data directory.Oops... looks like something wasn't changed. :-)
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.
Select * from MSFT_SIPApplicationConfigSetting where Backend="sql_instance"
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).
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.
Use LcsCDRYou need to change the red text to match your profile(s) so it 'cleans' the number.
SELECT CONVERT(varchar(10), VoipDetails.SessionIdTime, 103) [Start Date],
CONVERT(varchar(10), VoipDetails.SessionIdTime, 108) [Start Time],
CONVERT(varchar(10), SessionDetails.SessionEndTime, 103) [End Date],
CONVERT(varchar(10), SessionDetails.SessionEndTime, 108) [End Time],
CONVERT(varchar(10),SessionDetails.SessionEndTime - VoipDetails.SessionIdTime,108) [Time],
REPLACE(REPLACE(Phones.PhoneUri,';phone-context=LOCATIONPROFILEHERE',''),';phone-context=enterprise','') [From Number],
Users1.UserUri [From Sip],
REPLACE(REPLACE(Phones1.PhoneUri,';phone-context=LOCATIONPROFILEHERE',''),';phone-context=enterprise','') [Number Dialed],
Users3.UserUri [On Behalf Of],
Users4.UserUri [Referred By]
FROM VoipDetails LEFT OUTER JOIN
SessionDetails ON VoipDetails.SessionIdTime = SessionDetails.SessionIdTime AND
VoipDetails.SessionIdSeq = SessionDetails.SessionIdSeq LEFT OUTER JOIN
Phones ON VoipDetails.FromNumberId = Phones.PhoneId LEFT OUTER JOIN
Phones Phones1 ON VoipDetails.ConnectedNumberId = Phones1.PhoneId LEFT OUTER JOIN
Users Users1 ON SessionDetails.User1Id = Users1.UserId LEFT OUTER JOIN
Users Users2 ON SessionDetails.User2Id = Users2.UserId
LEFT OUTER JOIN Users Users3 ON SessionDetails.OnBehalfOfId = Users3.UserId
LEFT OUTER JOIN Users Users4 ON SessionDetails.ReferredById = Users4.UserId
where SessionDetails.ResponseCode = 200 and
Users2.UserUri is null and
SessionDetails.SessionEndTime is not null
order by VoipDetails.SessionIdTime
SELECT rtc.dbo.Resource.UserAtHost, CAST(rtcdyn.dbo.Endpoint.ClientApp AS varchar(128)) AS ClientAppThis will return a list showing what versions are being used and who's using them. It will even show if the same user is using different devices (as in one user on CWA, MOC, COMO, etc at the same time).
FROM rtcdyn.dbo.Endpoint INNER JOIN
rtc.dbo.Resource ON rtcdyn.dbo.Endpoint.OwnerId = rtc.dbo.Resource.ResourceId
order by UserAtHost
SELECT CAST(ClientApp AS varchar(128)) AS ClientApp, COUNT(*) AS Clients
FROM rtcdyn.dbo.Endpoint
Group by ClientApp