Gebruikers kunnen geen Office 365 Pro Plus opstarten

[winux]

Mijn vraag
Wij zijn bezig met de implementatie van Office 365 Pro Plus op een 2008 R2 RDS omgeving.
Daarvoor hebben we een clone van de productie machine gemaakt en deze als test ingericht.
Tijdens de installatie (via de ODT tool met XML file) krijgen we geen foutmelding. En wanneer de domein/lokale admin een office app opent, werkt alles naar behoren.
Echter wanneer een domein/lokale user inlogt krijg deze, bij het opstarten van een office app, de melding: something went wrong.

Relevante software en hardware die ik gebruik
Windows server 2008 R2,
XenApp 7.6
Office 365 Pro Plus

Wat ik al gevonden of geprobeerd heb
De installatie is via GPO ingericht om SharedComputerLicensing. De activatie geeft ook niet het probleem, maar dit krijg je wel heel veel terug wanneer je op de foutmelding Googled.
Wanneer de software op een werkstation geïnstalleerd wordt, (op dezelfde manier via ODT), werkt alles naar behoren, voor gebruikers en beheerders.
Heb gekeken met ProcessMonitor gekeken om te kijken of ik hier wat kunnen ontdekken. Echter worden we daar niet veel wijzer van.
Wanneer we de (test)user toekennen aan de lokale admin groep op de RDS server, kan deze user wel gebruik maken van de Office Apps.
Hiervoor hadden we een oudere versie van Office op de RDS omgeving geïnstalleerd staan, deze gaf geen problemen met het openen van de apps.

We zijn er redelijk 100% van overtuigd dat het een rechten probleem lokaal op de RDS server is. Echter krijg ik de vinger er niet op. Ben er eigenlijk ook wel van overtuigd dat weinig tot geen omgevingen ditzelfde probleem hebben. Omdat er eigenlijk niks op internet te vinden is over dit specifiek probleem.

Ben eigenlijk op zoek naar nieuwe inzichten of tools welke me op weg kunnen helpen in de goede richting voor deze troubleshooting.

[n0s]

Draait je Microsoft Office Click-to-Run Service?

Probeer eens

net localgroup Administrators localservice /add

fsutil resource setautoreset true C:\

netsh int ip reset resetlog.txt

[Rolfie]

winux schreef op woensdag 17 januari 2018 @ 12:44:
De installatie is via GPO ingericht om SharedComputerLicensing. De activatie geeft ook niet het probleem, maar dit krijg je wel heel veel terug wanneer je op de foutmelding Googled.

Wat als je het met de hand de install aftrapt?

Ben eigenlijk op zoek naar nieuwe inzichten of tools welke me op weg kunnen helpen in de goede richting voor deze troubleshooting.

Alvast een ticket inschieten bij MS? Je heb O365, je kan dus gewoon een ticket inschieten bij MS. Of je er met hun uitkomt, is een tweede, maar je hebt gewoon de mogelijkheden hiervoor.

[Question Mark]

Hoe staat je "Windows Installer RDS Compatibility" ingesteld?

(Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Application Compatibility)

[winux]

n0s schreef op woensdag 17 januari 2018 @ 12:49:
Draait je Microsoft Office Click-to-Run Service?

Probeer eens

net localgroup Administrators localservice /add

fsutil resource setautoreset true C:\

netsh int ip reset resetlog.txt

We maken gebruik van de Click-to-Run Service.
Bovenstaand heb ik uitgevoerd.
Helaas niet geholpen.

Rolfie schreef op woensdag 17 januari 2018 @ 12:50:
[...]

Wat als je het met de hand de install aftrapt?


[...]

Alvast een ticket inschieten bij MS? Je heb O365, je kan dus gewoon een ticket inschieten bij MS. Of je er met hun uitkomt, is een tweede, maar je hebt gewoon de mogelijkheden hiervoor.

Wanneer ik deze vanuit de portal installeerd, werkt het netjes onder de user (admin) waaronder deze in geïnstalleerd. Echter niet onder andere user, dan krijg ik foutmelding dat deze applicatie niet goed is geïnstalleerd.

Ticket inschieten hoop ik eigenlijk te voorkomen, omdat geheid de discussie ga krijgen dat de machine de oorzaak is en niet het office pakket.

Question Mark schreef op woensdag 17 januari 2018 @ 13:12:
Hoe staat je "Windows Installer RDS Compatibility" ingesteld?

(Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Application Compatibility)

In de lokale group policy staat deze niet ingesteld. In de group policy is deze niet aanwezig.

[ Voor 20% gewijzigd door winux op 17-01-2018 14:06 ]

[Dennism]

winux schreef op woensdag 17 januari 2018 @ 12:44:
Mijn vraag
Wij zijn bezig met de implementatie van Office 365 Pro Plus op een 2008 R2 RDS omgeving.
Daarvoor hebben we een clone van de productie machine gemaakt en deze als test ingericht.
Tijdens de installatie (via de ODT tool met XML file) krijgen we geen foutmelding. En wanneer de domein/lokale admin een office app opent, werkt alles naar behoren.
Echter wanneer een domein/lokale user inlogt krijg deze, bij het opstarten van een office app, de melding: something went wrong.

Relevante software en hardware die ik gebruik
Windows server 2008 R2,
XenApp 7.6
Office 365 Pro Plus

Wat ik al gevonden of geprobeerd heb
De installatie is via GPO ingericht om SharedComputerLicensing. De activatie geeft ook niet het probleem, maar dit krijg je wel heel veel terug wanneer je op de foutmelding Googled.
Wanneer de software op een werkstation geïnstalleerd wordt, (op dezelfde manier via ODT), werkt alles naar behoren, voor gebruikers en beheerders.
Heb gekeken met ProcessMonitor gekeken om te kijken of ik hier wat kunnen ontdekken. Echter worden we daar niet veel wijzer van.
Wanneer we de (test)user toekennen aan de lokale admin groep op de RDS server, kan deze user wel gebruik maken van de Office Apps.
Hiervoor hadden we een oudere versie van Office op de RDS omgeving geïnstalleerd staan, deze gaf geen problemen met het openen van de apps.

We zijn er redelijk 100% van overtuigd dat het een rechten probleem lokaal op de RDS server is. Echter krijg ik de vinger er niet op. Ben er eigenlijk ook wel van overtuigd dat weinig tot geen omgevingen ditzelfde probleem hebben. Omdat er eigenlijk niks op internet te vinden is over dit specifiek probleem.

Ben eigenlijk op zoek naar nieuwe inzichten of tools welke me op weg kunnen helpen in de goede richting voor deze troubleshooting.

Probeer het eens met een niet geclonede machine, zo uit mijn hoofd kan dit te maken hebben met het feit dat Full office installations en C2R niet echt lekker samen gaan op 1 machine. Ik heb dit ooit een keer eerder gezien, bleek dat er onderwater nog zaken bleven hangen van de oude office installatie. Destijds opgelost door gewoon een nieuwe machine de lucht in te schieten en die "schoon" in te richten. Toen was alles direct voor elkaar.

[winux]

Dennism schreef op woensdag 17 januari 2018 @ 15:38:
[...]


Probeer het eens met een niet geclonede machine, zo uit mijn hoofd kan dit te maken hebben met het feit dat Full office installations en C2R niet echt lekker samen gaan op 1 machine. Ik heb dit ooit een keer eerder gezien, bleek dat er onderwater nog zaken bleven hangen van de oude office installatie. Destijds opgelost door gewoon een nieuwe machine de lucht in te schieten en die "schoon" in te richten. Toen was alles direct voor elkaar.

Ik heb voordat ik de nieuwe office ging installeren de toolkit gebruikt om alles weg te halen. De vraag is of hij deze ook netjes allemaal verwijdert. Heb nu een nieuwe machine opgetuigd, welke geen enkele software bevat en deze toegevoegd in de citrix farm. Nu Office erop geïnstalleerd. Deze start zoals het zou moeten.
Volgende stap alle software erbij installeren en kijken of het nog blijft werken.

Wordt vervolgd....

[Killah_Priest]

winux schreef op woensdag 17 januari 2018 @ 16:25:
[...]


Ik heb voordat ik de nieuwe office ging installeren de toolkit gebruikt om alles weg te halen. De vraag is of hij deze ook netjes allemaal verwijdert. Heb nu een nieuwe machine opgetuigd, welke geen enkele software bevat en deze toegevoegd in de citrix farm. Nu Office erop geïnstalleerd. Deze start zoals het zou moeten.
Volgende stap alle software erbij installeren en kijken of het nog blijft werken.

Wordt vervolgd....

Als je Offscrub gedraaid hebt (Office Removal Tool van Microsoft) dan zou ook echt alles mbt Office weg moeten zijn.
Is het mogelijk om de inhoud van je XML file hier neer te zetten?

En dan nog een vraag (of eerder een opmerking) : waarom gebruiken jullie geen 2012R2 of 2016 server voor de TS voor Office 365? Ik heb in het verleden met vergelijkbare trajecten eigenlijk ook altijd meteen een nieuwe TS opgezet met een recent OS (aangezien met toch moet wennen aan een nieuwe look en feel, en het is consistenter met de look van Windows 10. Als jullie nog op 7 draaien dan heb ik niets gezegd uiteraard).

[ Voor 22% gewijzigd door Killah_Priest op 18-01-2018 15:00 ]

[matsuba]

Voor een RDS/XenApp zal je ook in de XML file aanmoeten geven dat het om gesharede licentie gebruik betreft. Via GPO wordt dit pas naderhand ingesteld.
<Property Name="SharedComputerLicensing" Value="1" />

Tevens zullen ook (indien aanwezig) viewers, onedrive ng en andere losse office gerelateerde applicaties verwijderd moeten worden, tenzij je gebruikt maakt van de zelfde build.

[ Voor 6% gewijzigd door matsuba op 18-01-2018 16:48 ]

[winux]

Killah_Priest schreef op donderdag 18 januari 2018 @ 14:58:
[...]


Als je Offscrub gedraaid hebt (Office Removal Tool van Microsoft) dan zou ook echt alles mbt Office weg moeten zijn.
Is het mogelijk om de inhoud van je XML file hier neer te zetten?

En dan nog een vraag (of eerder een opmerking) : waarom gebruiken jullie geen 2012R2 of 2016 server voor de TS voor Office 365? Ik heb in het verleden met vergelijkbare trajecten eigenlijk ook altijd meteen een nieuwe TS opgezet met een recent OS (aangezien met toch moet wennen aan een nieuwe look en feel, en het is consistenter met de look van Windows 10.

XML File:

<Configuration>
<Add OfficeClientEdition="32" SourcePath="\\server\folder\microsoft office 2016">
<Product ID="O365ProPlusRetail">
<Language ID="nl-nl" />
<ExcludeApp ID="Lync" />
<ExcludeApp ID="Groove" />
<ExcludeApp ID="Access" />
<ExcludeApp ID="OneDrive" />
</Product>
</Add>
<Display AcceptEULA="TRUE" Level="None" />
<Logging Level="Standard" Path="h:\" />
<Property Name="FORCEAPPSHUTDOWN" Value="FALSE" />
<Property Name="PinIconsToTaskbar" Value="FALSE" />
</Configuration>

Als jullie nog op 7 draaien dan heb ik niets gezegd uiteraard).

[Killah_Priest]

winux schreef op woensdag 24 januari 2018 @ 14:19:
[...]


XML File:


[...]


[...]

Kun je anders (conform de instructies op https://docs.microsoft.co...g-remote-desktop-services) het volgende toevoegen aan de xml?

XML:

<Property Name="SharedComputerLicensing" Value="1" />

Ik weet eerlijk gezegd niet of deze setting via GPO doorvoeren wel werkt voor RD session hosts (ik heb het zelf tot nu toe altijd via het XML bestand gedaan).

[winux]

Killah_Priest schreef op woensdag 24 januari 2018 @ 15:02:
[...]


Kun je anders (conform de instructies op https://docs.microsoft.co...g-remote-desktop-services) het volgende toevoegen aan de xml?

XML:

<Property Name="SharedComputerLicensing" Value="1" />

Ik weet eerlijk gezegd niet of deze setting via GPO doorvoeren wel werkt voor RD session hosts (ik heb het zelf tot nu toe altijd via het XML bestand gedaan).

Zoals al aangegeven, is de shared computer licensing error niet aan de orde.
De shared computer licentie melding hebben we mede veroorzaakt om te kijken of dit dezelfde melding kregen.
Nu we software op een nieuwe Server hebben uitgerold, werkt het naar behoren en krijgen we geen foutmelding als user.
Ook geen licentie/activatie error.
Vraag is echter wat er verschilt met de server waarom deze op de oude omgeving niet werkt.

[Torrenator]

Hallo allen,

Sinds 1,5 week heb ik hoor ook last van. Gelukkig heb ik samen met een collega een oplossing gevonden voor ons probleem en daarmee mogeljk ook jou probleem.

Wij kwamen op de onderstaande forumpost:

https://answers.microsoft...6e-47d7-9431-0d475071e21d

Hierin wordt verteld dat zodra je leesrechten geeft aan gebruikers binnen "C:\ProgramData\Microsoft\Windows\Start Menu" de gebruikers Excel, Word enz. wel kunnen opstarten.

Ook door middel van procmon kan dit worden bevestigd. Hierin moet je zoeken naar het officeclicktorun.exe process die onder het SYSTEM account draait. Als je daarvan de event properties bekijkt kun je zien dat deze een impersonation doet van de gebruiker die de applicatie wilt opstarten.