Als strategy consultant bij Wortell werk ik bij onze relaties aan definitiestudies, de implementatie en het duurzaam bruikbaar maken van de volledige Microsoft technologie stack.

---

Een vraag die het Wortell Consultancy team bij haar advieswerk voor SharePoint 2010 ECM opdrachten veelvuldig krijgt is: Hoe starten we (op een simpele wijze) met Managed Metadata? Andere vragen die we veelvuldig horen zijn:

- Wat zijn de succesfactoren voor een implementatie van Managed Metadata?

- Wat is haalbaar als we als organisatie net een begin willen maken met SharePoint als document en archiefbeheersysteem? Als in waar ligt de grens m.b.t. het aantal metadata velden per document?

We zijn er bij Wortell van overtuigd dat het een geval is van “Do More With Less”. Studies naar het gebruik van metadatering bij de classificatie van documenten wijzen uit dat gebruikers niet zitten te wachten op invulschermen met tientallen velden. Ze willen hooguit één of twee velden invullen en verwachten een hoop vrijheid bij het kunnen kiezen van de kenmerken. Als in ze verwachten een folksonomie, niet een taxonomie. De gebruiker wenst vandaag de dag veel meer zeggenschap over de termen waarmee ze hun documenten kunnen verrijken. Lees meer (0 reacties)

Recently a customer of ours who is rolling out Lync over several working companies asked us to develop a mechanism for intercompany invoicing of all PSTN calls. This may sound relatively easy to some but this scenario is not supported straight out of the box. So we did some investigating and came up with a solution that is based on MS SQL Server 2008 Reporting Services.

In the scenario of the customer, which is a large secondary education institute with over 12.000 students, PSTN calls made by staff members are cross-charged per location. In all there are 14 primary locations, including the backoffice, which will be using Lync for all their telephony needs.

To be able to send out a intercompany invoice we needed to combine the information from the Lync Call Detail Recording database with information contained in the Active Directory. This because the Lync CDR database does not contain any information on a user other than their SIP address and phone number. So what we set out to was to create a mechanism in SQL Server by which could query the Active Directory for the user’s name and location. This data is now loaded daily into a temporary table called AdUserImport which we added to the CDR database. In a SQL query it is subsequently joined on the relevant tables using the SIP address which can also be retrieved from AD.

The end result is quite simple, but very effective! With some rates information from the telephony provider our customer is now enabled to do some very detailed reporting on cost and usage per location. A sample of a intercompany invoice can be viewed below.

It’s in Dutch but I guess you can get the general gist of it. It shows cost for a given period and for a given location, subscription fees are calculated based on the total usage of the location as a fraction of the total usage for all locations. And off course there is the top 10 users, so that it is immediately visible by the financial administrator who is responsible for these enormous charges!

Some useful links:

OCS Usage Reporting Options

Call Detail Recording (CDR) Database Schema

How to avoid 1000 rows limitation when querying active directory (AD)

Thanks to Joost for pointing me in the right direction for the AD query :)