Office365 Shared contacts syncen naar een (SQL)DB met PS?

[HellStorm666]

Hi allemaal,

Ik zit met een uitdaging waar ik maar niet uit kom.
Maar waarvan ik weet dat het mogelijk moet zijn.

Wij hebben een Shared Contact lijst in Office365. Deze hebben we, op advies van Microsoft, in een Public Folder met een subfolder Contacts.
En die folder is door onze users te zien en door een paar ook aan te passen.

Onze contacten willen we ook in een Database op de server opslaan voor gebruik in een andere applicatie.
Bij voorkeur SQL, aangezien we SQL Server 2017 hebben draaien voor die andere applicatie.
Deze "Sync" mag een richting zijn, van Office365 naar SQL, maar mag ook beide kanten op.
Het mag automatisch gaan, maar op een trigger is ook geen probleem.

Dat het mogelijk is, is bewezen door onze telefooncentrale (3CX) welke de contacten gewoon netjes binnen haalt.

Het bedrijf die de andere applicatie voor ons maakt en inricht krijgt dit echter niet voor elkaar.
Zelf heb ik op google zitten zoeken en kan ook geen (PowerShell)scripts vinden die dit lijken te kunnen.

Weet iemand van jullie toevallig hoe ik dit aan kan pakken?

[HyperBart]

Een SQL connectie leggen naar O365 is afaik niet mogelijk. Wat je wel zou kunnen verkennen is regelmatig een export doen van de contacten in de PF's en deze importeren op SQL.

3CX kan inderdaad een PF map uitlezen waar contacten in zitten.

[HellStorm666]

HyperBart schreef op dinsdag 3 september 2019 @ 16:28:
Een SQL connectie leggen naar O365 is afaik niet mogelijk. Wat je wel zou kunnen verkennen is regelmatig een export doen van de contacten in de PF's en deze importeren op SQL.

3CX kan inderdaad een PF map uitlezen waar contacten in zitten.

Enig idee hoe 3CX deze PF dan uitleest?

Opzich hoeft het niet direct SQL in. Met PowerShell het uitlezen en in een file opslaan en deze vervolgens SQL in werken is ook prima.

Grootste probleem nu is dat we niet een de contact uit die PF gescrobbled krijgen.

[HyperBart]

HellStorm666 schreef op dinsdag 3 september 2019 @ 16:33:
[...]

Enig idee hoe 3CX deze PF dan uitleest?

https://www.3cx.com/docs/manual/pbx-crm-integration/

Opzich hoeft het niet direct SQL in. Met PowerShell het uitlezen en in een file opslaan en deze vervolgens SQL in werken is ook prima.

Grootste probleem nu is dat we niet een de contact uit die PF gescrobbled krijgen.

Je gaat een connectie moeten maken naar Exchange. Via EWS kan je dit soort data in scripts imo het meest efficient query'en:

https://docs.microsoft.co...-by-using-ews-in-exchange

Het bedrijf die de andere applicatie voor ons maakt en inricht krijgt dit echter niet voor elkaar.
Zelf heb ik op google zitten zoeken en kan ook geen (PowerShell)scripts vinden die dit lijken te kunnen.

Klinkt als een heeeeeeeerlijke meedenkende applicatie-leverancier .

[ Voor 16% gewijzigd door HyperBart op 04-09-2019 09:48 ]

[Killah_Priest]

HyperBart schreef op woensdag 4 september 2019 @ 09:46:
[...]

https://www.3cx.com/docs/manual/pbx-crm-integration/

[...]


Je gaat een connectie moeten maken naar Exchange. Via EWS kan je dit soort data in scripts imo het meest efficient query'en:

https://docs.microsoft.co...-by-using-ews-in-exchange


[...]

Klinkt als een heeeeeeeerlijke meedenkende applicatie-leverancier .

Yup, EWS is volgens mij ook de manier (ik weet niet of de REST API's van office 365 inmiddels al lekker werken met public folders).
Gewoon data uitlezen via EWS (public folders zijn gewoon te benaderen via EWS alleen zijn er weinig voorbeelden te vinden) en direct in SQL pompen.

Ik vind het overigens ook vreemd dat zo'n leverancier niet meedenkt, bij eerdere werkgevers schreef ik juist scripts welke dit soort dingen deden met EWS (en dat vanuit een rol als systeembeheer)

[HellStorm666]

Mijn kennis van EWS is 0,0.
Weet eerlijk gezegd niet eens wat t is/betekent zonder op te zoeken (morgen dus maar ff doen).

Thnx iig voor de hulp. Weet nu waar ik t moet gaan zoeken :-)

[Killah_Priest]

HellStorm666 schreef op woensdag 4 september 2019 @ 21:00:
Mijn kennis van EWS is 0,0.
Weet eerlijk gezegd niet eens wat t is/betekent zonder op te zoeken (morgen dus maar ff doen).

Thnx iig voor de hulp. Weet nu waar ik t moet gaan zoeken :-)

Een zeer goede plek om te starten met EWS (Exchange Web Services) is de blog van Glen Scales: https://gsexdev.blogspot.com/

Hier staat een heleboel uitleg icm code voorbeelden in Powershell. Ook zaken welke niet duidelijk gedocumenteerd zijn door Microsoft staat hier beschreven.

[HyperBart]

HellStorm666 schreef op woensdag 4 september 2019 @ 21:00:
Mijn kennis van EWS is 0,0.
Weet eerlijk gezegd niet eens wat t is/betekent zonder op te zoeken (morgen dus maar ff doen).

Thnx iig voor de hulp. Weet nu waar ik t moet gaan zoeken :-)

Jij moet dat imo ook niet doen maar je applicatieboer. Als dit soort dingen al moeilijk ligt voor een (wat ik inschat als een) custom pakket voor jullie dan krab ik me toch even in het haar hoe kwalitatief de rest moet zijn

[Killah_Priest]

HyperBart schreef op donderdag 5 september 2019 @ 10:42:
[...]

Jij moet dat imo ook niet doen maar je applicatieboer. Als dit soort dingen al moeilijk ligt voor een (wat ik inschat als een) custom pakket voor jullie dan krab ik me toch even in het haar hoe kwalitatief de rest moet zijn

Dit dus.
Ik bouwde veel Powershell scripts (en soms services in C#) om zaken met oa EWS te doen vanuit een rol als systeembeheer (de werkgever gaf mij hier de tijd voor en legde hiet ook geen druk op. Het waa zeg maar "nice to have").
Als ik vanuit een systeembeheer rol dit soort scripts binnen een dag al klaar had om te testen in een testomgeving (waarna het eigenlijk altijd vrij snel naar productie kon) dan verwacht ik van een applicatie boer dat zij dit soort zaken ook gewoon binnen afzienbare tijd kunnen bouwen.

[HellStorm666]

Dat leek mij dus ook al.

"Hij" is nu al een week of 4 verder en krijgt het niet werkende zegt ie.
Wel vanuit een User contacten lijst, maar niet vanuit de Openbare mappen (de methode die Microsoft adviseerd om een bedrijfs breed klanten bestand te hebben).

Ik heb hem nu in ieder geval die gsexdev blogspot gestuurd. hopen dat ie daar wat mee kan.
Volgens mij doet ie normaal niets met PowerShell, maar vooral met C en SQL.
Andere aanpassingen en maatwerk vragen heeft ie nl wel heel mooi opgelost.

[jorisros]

Je zou het op met het command get-contact kunnen uitlezen in powershell, en dit dan weer door sturen naar de sqlserver.

https://docs.microsoft.co...-contact?view=exchange-ps

[Killah_Priest]

Ik heb even een simpel voorbeeldje in Powershell in elkaar gezet waarmee je dmv het account waarmee je inlogt op 365, de public folders opvraagt en vervolgens de items uitleest uit een specifieke public folder.

PowerShell:

# Add the Assembly for EWS
Add-Type -Path "C:\Assemblies\Microsoft.Exchange.WebServices.2.2\lib\40\Microsoft.Exchange.WebServices.dll"

#FolderView en ItemView objecten voor het zoeken (deze geven aan hoeveel items er terug komen. Tevens kun je hier ook filters aanmaken)
$FolderView = [Microsoft.Exchange.WebServices.Data.FolderView]::new(100)
$ItemView = [Microsoft.Exchange.WebServices.Data.ItemView]::new(100)

# Email adres
$EmailAddress = "[e-mail]"
# Password : normaal lees je dit uit uit een encrypted bestand oid
$Pass = 'supersecretpassword'
# Maak credential object
$Cred = [Microsoft.Exchange.WebServices.Data.WebCredentials]::new($EmailAddress,$Pass)
# Maak Exchange Service Object
$EX = [Microsoft.Exchange.WebServices.Data.ExchangeService]::new()
# Stel de credentials in
$EX.Credentials = $Cred
# Doe Autodiscover
$EX.AutodiscoverUrl($EmailAddress,{$true})
# Als de autodiscover lukt ben je ingelogd. Nu moet je de Public Folder ID achterhalen

# Nu moeten we de public folder ID achterhalen. Dit kan dmv FindFolders op de root.
$Folders = $EX.FindFolders([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::PublicFoldersRoot,$FolderView)
# Nu heb je een lijst met alle "root" public folders. In mijn testomgeving heb ik maar één public folder.

# Even de betreffende folder in een variable stoppen. DE id is de Id waar je op kunt "binden" waarna je de items uit kunt lezen
$TargetFolder = $Folders | Where-Object {$_.DisplayName -eq 'test'}
# Hier maak ik de "binding"
$FolderBinding = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($EX, $TargetFolder.Id)
# en nu kun je de items, subfolders etc opvragen uit de betreffende folder
$PublicFolderItems = $FolderBinding.FindItems($ItemView)

# Items worden altijd maar met een x aantal properties returned.
# Met bv de Load method kun je het gehele item (inclusief attachments) inladen. Ook kun je een select aantal properties inladen
# hier laad ik het eerste item in
$PublicFolderItems.Items[0].Load()

Dit is een simpel voorbeeld waarmee de betreffende developer naar mijn idee toch wel erg ver moet kunnen komen (ik heb het getest tijdens het schrijven in 10 minuutjes, bij mij werkt het)

Resultaat wat ik terugkrijg (testitem uit een public folder, grootste deel van de output heb ik weggelaten hier)
ConversationIndex : {1, 1, 213, 100...}
ConversationTopic : testbericht
From : testert <SMTP:tester@***.onmicrosoft.com>
InternetMessageId : <[e-mail]>
IsRead : False
PostedTime : 6-9-2019 12:53:47

jorisros schreef op vrijdag 6 september 2019 @ 13:00:
Je zou het op met het command get-contact kunnen uitlezen in powershell, en dit dan weer door sturen naar de sqlserver.

https://docs.microsoft.co...-contact?view=exchange-ps

Voorzover ik weet werkt Get-Contact niet op public folders.

[ Voor 6% gewijzigd door Killah_Priest op 06-09-2019 13:13 ]

[HellStorm666]

Killah_Priest schreef op vrijdag 6 september 2019 @ 11:01:
[...]


Dit dus.
Ik bouwde veel Powershell scripts (en soms services in C#) om zaken met oa EWS te doen vanuit een rol als systeembeheer (de werkgever gaf mij hier de tijd voor en legde hiet ook geen druk op. Het waa zeg maar "nice to have").
Als ik vanuit een systeembeheer rol dit soort scripts binnen een dag al klaar had om te testen in een testomgeving (waarna het eigenlijk altijd vrij snel naar productie kon) dan verwacht ik van een applicatie boer dat zij dit soort zaken ook gewoon binnen afzienbare tijd kunnen bouwen.

Met de voorbeelden en blogpost is het hem gelukt om het script te maken en de data in het programma te krijgen.

Super bedankt voor de hulp!!