Snelkoppelingen blijven na upgrade Office 2010-2013

[H8M3CuzUaintM3]

Goedenmiddag,

Ik ben bezig met een upgrade van Office 2010 naar Office 2013 d.m.v. SCCM. Hierin maken we gebruik van Microsoft Office Customization Tool(OCT). De upgrade wordt uitgevoerd via SCCM en gaat prima alleen hebben we een rest puntje.

- Snelkoppelingen van Office 2010 op de desktop en taskbar moeten(het liefst tijdens de upgrade) worden verwijderd.

Heeft iemand hier ervaring mee of een goede tip voor aangezien de upgrade wordt uitgevoerd met het System account en dus niet in de AppData folder komt.

[ Voor 10% gewijzigd door H8M3CuzUaintM3 op 08-02-2016 14:02 ]

[redfoxert]

Hebben users die zelf aangemaakt? Dan lijkt me dat een vrij lastig geval tenzij je een script maakt dat de meest voorkomende shortcuts op desktops en taskbars verwijdert. Volgens mij kan je het met de OCT niet regelen of daar zou je dan ook custom delete acties moeten aanmaken.

[H8M3CuzUaintM3]

redfoxert schreef op maandag 08 februari 2016 @ 14:02:
Hebben users die zelf aangemaakt? Dan lijkt me dat een vrij lastig geval tenzij je een script maakt dat de meest voorkomende shortcuts op desktops en taskbars verwijdert. Volgens mij kan je het met de OCT niet regelen of daar zou je dan ook custom delete acties moeten aanmaken.

Dit zijn inderdaad shortcuts die gebruikers zelf hebben aangemaakt op hun desktop of taskbar. Ik heb hier dus een oplossing voor nodig!

[ Voor 4% gewijzigd door H8M3CuzUaintM3 op 08-02-2016 15:11 ]

[sanfranjake]

De meest efficiënte oplossing lijkt mij een regeltje opnemen in het document wat je aan gebruikers verspreidt over de migratie: "Let op! : Snelkoppelingen naar de oude Office-pakketten kunnen wij niet voor je verwijderen. Als je zelf snelkoppelingen in je taakbalk of bureaublad had gemaakt moet je die handmatig verwijderen en opnieuw maken naar de nieuwe office-versie."

Want hoe wil je bijvoorbeeld de snelkoppeling van Pietje vinden die de naam "Brief typen" heeft ipv "Word" of een andere veelvoorkomende naam?

[Kalief]

Informatie of instructies zijn niet voldoende. De gebruikers lezen die niet, snappen ze niet, weten niet wanneer die wel en niet van toepassing zijn. En gaan dus de helpdesk bellen met "ik open mijn document en krijg de melding dat ie weg is, paniek, alles is weg!"

Je kunt een script laten draaien die na inloggen scant op .lnk bestanden met een pad dat niet meer bestaat en die verwijdert. (Ik ga er dan van uit dat paden naar gebruikers- en afdelingsfolders veranderen.)

[H8M3CuzUaintM3]

sanfranjake schreef op maandag 08 februari 2016 @ 15:26:
De meest efficiënte oplossing lijkt mij een regeltje opnemen in het document wat je aan gebruikers verspreidt over de migratie: "Let op! : Snelkoppelingen naar de oude Office-pakketten kunnen wij niet voor je verwijderen. Als je zelf snelkoppelingen in je taakbalk of bureaublad had gemaakt moet je die handmatig verwijderen en opnieuw maken naar de nieuwe office-versie."

Want hoe wil je bijvoorbeeld de snelkoppeling van Pietje vinden die de naam "Brief typen" heeft ipv "Word" of een andere veelvoorkomende naam?

Ben ik het niet mee eens, welke beheerder laat zoiets nou aan zijn gebruikers over?

Dit moet toch mogelijk zijn met een script/gpo, alleen ik ben op zoek naar welke?

Gebruikers die hun snelkoppeling van bijvoorbeeld "Word 2010" hebben gewijzigd neem ik voor lief

[H8M3CuzUaintM3]

Kalief schreef op maandag 08 februari 2016 @ 15:32:
Informatie of instructies zijn niet voldoende. De gebruikers lezen die niet, snappen ze niet, weten niet wanneer die wel en niet van toepassing zijn. En gaan dus de helpdesk bellen met "ik open mijn document en krijg de melding dat ie weg is, paniek, alles is weg!"

Je kunt een script laten draaien die na inloggen scant op .lnk bestanden met een pad dat niet meer bestaat en die verwijdert. (Ik ga er dan van uit dat paden naar gebruikers- en afdelingsfolders veranderen.)

Hier ben ik het volledig mee eens... heb je toevallig een script hiervoor of een site die mij verder kan helpen?

Bedankt voor je imput alvast!

[sanfranjake]

Oke, dan begin ik bejaard te worden. Mensen na laten denken is blijkbaar niet meer van deze tijd. Alles moet gerobotiseerd worden, zelfs als daar meer tijd in gaat zitten dan het uitvoeren door de mensen zelf.

Ik trek me terug.

[Kalief]

sanfranjake schreef op maandag 08 februari 2016 @ 21:10:
Mensen na laten denken is blijkbaar niet meer van deze tijd. Alles moet gerobotiseerd worden, zelfs als daar meer tijd in gaat zitten dan het uitvoeren door de mensen zelf.

Hoeveel tijd denk je dat gaat zitten in het helpdesken? Liever een beetje extra tijd steken in de afwerking van de migratie door 2/3e lijn dan veel extra tijd vergen van 1e lijn en gebruikers.

[Question Mark]

supra_indo schreef op maandag 08 februari 2016 @ 15:32:
[...]


Ben ik het niet mee eens, welke beheerder laat zoiets nou aan zijn gebruikers over?

Dezelfde beheerder die destijds toegestaan heeft om zelf custom shortcuts aan te maken.

Deze ellende is precies de reden waarom ik altijd adviseer om dit tegen te gaan:

• Geen custom shortcuts
• Geen eigen drive mappings
• Etc.

Gewoon alles vanaf een centrale lokatie geplaatst en beheerd.

[Razwer]

PowerShell:

$userprofile = $env:USERPROFILE
$Todelete = Get-ChildItem -Path $userprofile -Filter *.lnk -Recurse
Foreach ($file in $Todelete) {
    If ($file -match "*word*" -OR $file -match "*excel*")  {
        Remove-Item $file -force        
    }
}

ff runnen voordat je nieuwe office er op knalt.

Script is niet getest overigens.

[H8M3CuzUaintM3]

Razwer schreef op dinsdag 09 februari 2016 @ 14:05:

PowerShell:

$userprofile = $env:USERPROFILE
$Todelete = Get-ChildItem -Path $userprofile -Filter *.lnk -Recurse
Foreach ($file in $Todelete) {
    If ($file -match "*word*" -OR $file -match "*excel*")  {
        Remove-Item $file -force        
    }
}

ff runnen voordat je nieuwe office er op knalt.

Script is niet getest overigens.

Verwijderd dit script de desktop en ook de taskbar icons?

[Razwer]

volgens mij wel, alles wat een shortcut is wordt uit het profiel geknikkerd. Let wel, heb m ff snel uit de mouw geschud dus je moet hem wel testen. Ook is misschien het -match filter voor verbetering vatbaar, maar dat mag je zelf oordelen.

[Craven]

Je wilt momenteel het beste van 2 werelden dat eigenlijk niet verenigbaar is.

Je hebt een omgeving die je niet volledig in de hand hebt. Gebruikers maken zelf hun eigen shortcuts aan. Gevolg daarvan is dat je bij een migratie dus ook niet alles volledig in eigen hand hebt. Gebruiker maakt zijn shortcut aan --> gebruiker is verantwoordelijk.

Wat jij wilt is een omgeving die je volledig in eigen hand hebt en volledige controle. Veelvoorkomend trekje bij IT'ers. Hoeft niet slecht te zijn maar dan moet je gebruikers niet toestaan hun eigen shortcuts te maken.

In any case, het scriptje van Razwer verwijdert de shortcuts in het userprofile. Afhankelijk van hoe jou omgeving eruit ziet is het het meest logisch om deze @logon te draaien (logonscripts vind ik nogal vies overigens, helemaal zonder logging).

Just my 2 cents, je gaat te ver met de upgrade. Gebruikers (het zijn eigenlijk gewoon mensen of medewerkers trouwens) kunnen zelf ook verantwoordelijkheid hebben alleen is dat wel iets wat gecommuniceerd moet worden. Als communicatie naar die betreffende medewerkers niet lukt want "De gebruikers lezen die niet" dan moet je daar wat aan gaan doen en niet alles maar op technisch vlak willen afvangen. Technische oplossingen kosten altijd meer tijd dan organisatorische oplossingen als die van Razwer (no offense).

[Razwer]

Craven schreef op dinsdag 09 februari 2016 @ 14:39:
Technische oplossingen kosten altijd meer tijd dan organisatorische oplossingen als die van Razwer (no offense).

none taken

[H8M3CuzUaintM3]

Craven schreef op dinsdag 09 februari 2016 @ 14:39:
Je wilt momenteel het beste van 2 werelden dat eigenlijk niet verenigbaar is.

Je hebt een omgeving die je niet volledig in de hand hebt. Gebruikers maken zelf hun eigen shortcuts aan. Gevolg daarvan is dat je bij een migratie dus ook niet alles volledig in eigen hand hebt. Gebruiker maakt zijn shortcut aan --> gebruiker is verantwoordelijk.

Wat jij wilt is een omgeving die je volledig in eigen hand hebt en volledige controle. Veelvoorkomend trekje bij IT'ers. Hoeft niet slecht te zijn maar dan moet je gebruikers niet toestaan hun eigen shortcuts te maken.

In any case, het scriptje van Razwer verwijdert de shortcuts in het userprofile. Afhankelijk van hoe jou omgeving eruit ziet is het het meest logisch om deze @logon te draaien (logonscripts vind ik nogal vies overigens, helemaal zonder logging).

Just my 2 cents, je gaat te ver met de upgrade. Gebruikers (het zijn eigenlijk gewoon mensen of medewerkers trouwens) kunnen zelf ook verantwoordelijkheid hebben alleen is dat wel iets wat gecommuniceerd moet worden. Als communicatie naar die betreffende medewerkers niet lukt want "De gebruikers lezen die niet" dan moet je daar wat aan gaan doen en niet alles maar op technisch vlak willen afvangen. Technische oplossingen kosten altijd meer tijd dan organisatorische oplossingen als die van Razwer (no offense).

Bedankt voor je opmerking maar zoiets wil je automatiseren en niet op goed geluk laten aankomen of verantwoordelijkheid aan de gebruikers. Helemaal niet als it dienstverlener naar je klant toe no offense maar aan je antwoord heb ik dus helemaal niks

[H8M3CuzUaintM3]

Razwer schreef op dinsdag 09 februari 2016 @ 14:27:
volgens mij wel, alles wat een shortcut is wordt uit het profiel geknikkerd. Let wel, heb m ff snel uit de mouw geschud dus je moet hem wel testen. Ook is misschien het -match filter voor verbetering vatbaar, maar dat mag je zelf oordelen.

Ik ga het script vanavond op een test vm testen! Word vervolgd

[Question Mark]

supra_indo schreef op dinsdag 09 februari 2016 @ 15:19:
[...]


Bedankt voor je opmerking maar zoiets wil je automatiseren en niet op goed geluk laten aankomen of verantwoordelijkheid aan de gebruikers.

Maar nu ga je vragen en belletjes krijgen van gebruikers dat hun snelkoppelingen verwijderd zijn. Als we het toch hebben over verantwoordelijkheden en klantvriendelijkheid, zul je deze snelkoppelingen moeten vervangen door snelkoppelingen naar hun nieuwe produkten.

En da's lastig.... Kom er maar eens achter waar gebruikers allemaal snelkoppeling hebben staan. Voor hetzelfde geld staan ze ergens verstopt op hun home-drive...

Verder: je vraagt ook naar tips:

supra_indo schreef op maandag 08 februari 2016 @ 13:59:
Heeft iemand hier ervaring mee of een goede tip voor aangezien de upgrade wordt uitgevoerd met het System account en dus niet in de AppData folder komt.

Dat mensen dan wat breder gaan denken is hier een gevolg van. En wees blij dat men dit doet.

[Craven]

supra_indo schreef op dinsdag 09 februari 2016 @ 15:19:
[...]


Bedankt voor je opmerking maar zoiets wil je automatiseren en niet op goed geluk laten aankomen of verantwoordelijkheid aan de gebruikers. Helemaal niet als it dienstverlener naar je klant toe no offense maar aan je antwoord heb ik dus helemaal niks

Je hebt je oplossingsrichting dus al gekozen. Je vraag was: "iemand tips?". Je bedoelde echter: "Ik wil graag via gpo/script/technisch dingetje alle shortcuts van Office 2010 verwijderen".

De eerste vraag lijkt me er 1 voor tweakers.net want dat is iets waar je over kan discussieren. De 2e vraag is nog steeds wel iets voor tweakers.net maar kun je ook net zo makkelijk op google vinden. Een simpele "powershell delete files in folder" brengt je bij https://technet.microsoft.com/en-us/library/ee176938.aspx.
Met een beetje leeswerk zit je dan op deze code:

code:

Remove-Item c:\scripts\* -include .wav,.mp3

Als je daar enigszins logisch over nadenkt en get-help naleest kom je binnen no-time op

code:

Remove-Item $env:USERPROFILE  -recurse -include *word*.lnk,*excel*.lnk -force

Laatste stukje code zou overigens hetzelfde moeten doen als Razwer maar dan een stuk sneller.

[H8M3CuzUaintM3]

Question Mark schreef op dinsdag 09 februari 2016 @ 15:31:
[...]

Maar nu ga je vragen en belletjes krijgen van gebruikers dat hun snelkoppelingen verwijderd zijn. Als we het toch hebben over verantwoordelijkheden en klantvriendelijkheid, zul je deze snelkoppelingen moeten vervangen door snelkoppelingen naar hun nieuwe produkten.

En da's lastig.... Kom er maar eens achter waar gebruikers allemaal snelkoppeling hebben staan. Voor hetzelfde geld staan ze ergens verstopt op hun home-drive...

Verder: je vraagt ook naar tips:


[...]

Dat mensen dan wat breder gaan denken is hier een gevolg van. En wees blij dat men dit doet.

Ik ben het zeker eens met een gedeelte van de contex alleen er wordt duidelijk gecommuniceerd dat de snelkoppelingen worden verwijderd en hoe gebruikers nieuwe snelkoppelingen kunnen maken. Eventueel zullen we in de OCT verwerken dat er nieuwe snelkoppelingen aangemaakt worden.

In deze gaat het alleen om Office 2010 snelkoppelingen!

Bedankt voor je info

[H8M3CuzUaintM3]

Ik heb onderstaand vbs script getest om hem in de directory te plaatsen waar de pinned taskbar icons staan. De reden hiervoor is het verwijderen van de .lnk van zijn directory verwijderd niet het icon op de taskbar maar maakt hem onbuikbaar. Onderstaande commando's moeten dan worden uitgevoerd vanuit de locatie waar de pinned icons staan in commandline.

cscript removelink.vbs "Microsoft Excel 2010"
cscript removelinks.vbs "Microsoft Word 2010"
cscript removelinks.vbs "Microsoft Outlook 2010"

Tevens heb ik het Remove-Item powershell commando getest maar deze werkte niet

code:

Option Explicit
'Const CSIDL_COMMON_PROGRAMS = &H17
Dim ShellApp, FSO, strLinkName,LinkFolder,LinkItems,LnkFile,Item,wshShell,strUserProfile
Set ShellApp = CreateObject("Shell.Application")
Set FSO = CreateObject("Scripting.FileSystemObject")


strLinkName = WScript.Arguments.Item(0)

Set wshShell = CreateObject( "WScript.Shell" )
strUserProfile =  wshShell.ExpandEnvironmentStrings( "%userprofile%" )
'wshShell = Nothing

Set LinkFolder =  ShellApp.NameSpace(strUserProfile & "\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar")
LnkFile = strUserProfile & "\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar\" & strLinkName & ".lnk"

'If(FSO.FileExists(LnkFile)) Then
    Dim tmp, verb
    Set LinkItems = LinkFolder.Items()
    For Each item in LinkItems
        WScript.Echo item.Name
        If (item.Name = strLinkName) Then
            For Each verb in item.Verbs
                If (verb.Name = "Unpin from Tas&kbar") Then 
                    verb.DoIt
                End If
            Next
        End If
    Next
'End If

Set FSO = Nothing
Set ShellApp = Nothing

[H8M3CuzUaintM3]

Is het mogelijk om de .ost file die is opgebouwd met Office 2010 weer te gebruiken na een upgrade naar Office 2013?

[Question Mark]

Je mag ook zelf iets meer moeite gaan doen.. De eerste hit in Google geeft het antwoord al:

By default, when Outlook 2013 is installed, a new compressed version of the Outlook data file (.ost) is created. This new compressed version of the .ost is up to 40% smaller than the size of the .ost files that were created in earlier versions of Outlook. If you must keep Outlook 2013 from creating a new compressed Outlook data file (.ost), use the Outlook Group Policy template (Outlk15.admx) to enable the Do not create new OST file on upgrade policy. Find this setting under User Configuration\Administrative Templates\Microsoft Outlook 2013\Account Settings\Exchange. There’s more information here: Plan a Cached Exchange Mode deployment in Outlook 2013.

Bij deze wel even het verzoek om ook zelf even wat initiatief te gaan tonen. Simpelweg een vraag dumpen is niet de bedoeling.

[ Voor 8% gewijzigd door Question Mark op 10-02-2016 21:48 ]