Windows 10: register startup item vertraagd laten opstarten

[evan_nl]

Heb al veel gezocht op het web maar helaas nog niet iets kunnen vinden. Ik weet ook niet of het mogelijk is maar wellicht is hier iemand die ideeën heeft.

Op client PC's met Windows 10 Enterprise in het netwerk wordt een stukje software via het register opgestart bij sommige gebruikers. In het profiel staat dan een entry in: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

Nou wil ik deze entry laten vertragen bij het inloggen met een aantal seconden. Net zoals je bijvoorbeeld in bat script TIMEOUT /T kan gebruiken, is er ook zoiets mogelijk met een register item door er iets aan toe te voegen?

[Room42]

Waarom dan niet gewoon een batch file met timeout /t?

[Brahiewahiewa]

Met ^
En anders zou je kunnen vertellen om welke taak het gaat en waarom je die timeout nodig hebt.
Ik voel iets aankomen met network drives die nog niet beschikbaar zijn

[evan_nl]

Ik zal het even verder in detail uitleggen. Het gaat op een een stukje cliënt software (Nextcloud) welke bestanden moet syncen in de homedir van de gebruiker. Probleem daarmee is dat de credentials niet bewaard worden als je inlogt op een andere PC met z'n roaming profile. Daarvoor heb ik voor alle users in de OU een batch file met ROBOCOPY draaien die vanuit hun Appdata\Local\Microsoft\credentials deze bij uitloggen wegschrijft (logoff script) naar een mapje in de homedir, om vervolgens bij inloggen (logon script) weer teruggezet te worden in de local appdata.

Probleem is nu dat die credential files meestal pas 2-3 seconden weer in de local appdata staan nadat de cliëntsoftware is opgestart en deze dus niet tijdig klaar staan voor de applicatie. Die credentials heen en weer schrijven mag gerust voor elke user in de OU gebeuren, maar niet iedereen in deze OU gebruikt de cliëntsoftware, dus wil ik dit niet voor iedere user ook een batch script die de applicatie opstart.

Pas als gebruikers de cliëntsoftware instellen binnen hun omgeving/profiel wordt de registerwaarde weggeschreven in de HCU\Software\Microsoft\Windows\CurrentVersion\Run. Dus leek mij het netste om te kijken of ik deze registerstartup waarde kan vertragen. Tevens zorgt een andere GPO in de OU ervoor dat als de startup waarde daar in register aanwezig is hier nog wat aan toevoegt (--confdir %APPDATA%\Nextcloud) om de configuratiefiles die de instellingen (zonder credentials) van de applicatie in de roaming appdata zet.

[Brahiewahiewa]

Heb je https://github.com/ownclo...84#issuecomment-247280687 gelezen?

[MAX3400]

Waarom niet een WMI-target op de AD-group met de NextCloud users en dan een GPO bouwen met User Configuration, Script en dan kiezen voor Run Last?

Je bent nu een klein beetje problemen aan het veroorzaken door logon-scripts te gebruiken; die hebben namelijl absolute voorraang boven policies.

[ Voor 12% gewijzigd door MAX3400 op 25-08-2018 23:05 ]

[evan_nl]

@Brahiewahiewa, dit had ik inderdaad gelezen, ik heb reeds al geimplementeerd dat als de registerkey aanwezig is deze aangepast wordt met --confdir %appdata%\Nextcloud erachter. Helaas neemt dit niet de credentials mee alleen de configuratie van de client (syncpath, username, etc). Eigenlijk zoek ik een methode dat als deze registerkey aanwezig is de clientsoftware met enkele seconden vertraagd wordt opgestart.

@MAX3400, je doelt er dus op om Nextcloud niet via register te laten starten maar vertraagd via een Powershell script als ik het goed begrijp? Nog geen ervaring met WMI targeting, maar wat ik zo lees op het net kan dat enkel gebruikt worden voor specificieke PC's? In mijn situatie is er een select aantal users uit diverse OU's welke Nextcloud client iets vertraagd gestart moeten krijgen nadat de credentials gekopieerd zijn, zij kunnen op elke PC gaan inloggen, hebben dus geen vaste plek.

[Killah_Priest]

evan_nl schreef op zondag 26 augustus 2018 @ 23:08:
@Brahiewahiewa, dit had ik inderdaad gelezen, ik heb reeds al geimplementeerd dat als de registerkey aanwezig is deze aangepast wordt met --confdir %appdata%\Nextcloud erachter. Helaas neemt dit niet de credentials mee alleen de configuratie van de client (syncpath, username, etc). Eigenlijk zoek ik een methode dat als deze registerkey aanwezig is de clientsoftware met enkele seconden vertraagd wordt opgestart.

@MAX3400, je doelt er dus op om Nextcloud niet via register te laten starten maar vertraagd via een Powershell script als ik het goed begrijp? Nog geen ervaring met WMI targeting, maar wat ik zo lees op het net kan dat enkel gebruikt worden voor specificieke PC's? In mijn situatie is er een select aantal users uit diverse OU's welke Nextcloud client iets vertraagd gestart moeten krijgen nadat de credentials gekopieerd zijn, zij kunnen op elke PC gaan inloggen, hebben dus geen vaste plek.

GPO met een startup script erin alleen getarget op een groep waar de betreffende users in staan?

[Rolfie]

Scheduletask maken die x minuten later opstart?

[evan_nl]

Thanx voor de tips heb nu inderdaad een paar testusers aan nieuwe groep toegevoegd. Vervolgens bij een nieuwe GPO authenticated users "Apply group policy" weg gehaald en bij Security Filtering de nieuwe groep toegevoegd. Dat werkt uitstekend zodat deze GPO alleen voor specifieke users werkt die van deze extra/secundaire/aanvullende groep lid zijn.

Nu nog even testen of ik de client vertraagd ga laten opstarten via powershell of scheduledtask.

Dank voor alle input zover!

[Question Mark]

De issue lijkt overigens gefixed te zijn. Je zou daar eens mee kunnen gaan testen:

https://github.com/nextcloud/desktop/issues/569

Starting with e0a14ca the desktop client has proper support for roaming profiles on Windows operating systems.

Nog wel een issue met het juist opslaan van het wachtwoord, maar ook daar is een fix voor:

Please update the build toolchain, so QtKeychain 0.9.1 is used for the 2.5 release (also see owncloud/client#6729).

[evan_nl]

Question Mark schreef op dinsdag 28 augustus 2018 @ te 16:13:
De issue lijkt overigens gefixed te zijn. Je zou daar eens mee kunnen gaan testen:

https://github.com/nextcloud/desktop/issues/569


[...]


Nog wel een issue met het juist opslaan van het wachtwoord, maar ook daar is een fix voor:


[...]

Ja dank die had ik al gelezen! Helaas werken de laatste daily builds niet met apppasword. Is dus niet werkbaar voor ons en waarschijnlijk is tevens een dailybuild gebruiken ook geen goed idee in productie omgeving