19:59:58 #startmeeting Ansible Windows Working Group 19:59:58 Meeting started Tue Apr 14 19:59:58 2020 UTC. 19:59:58 This meeting is logged and archived in a public location. 19:59:58 The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:59:58 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:59:58 The meeting name has been set to 'ansible_windows_working_group' 20:00:10 Bah, 2s early 20:01:20 yo 20:01:20 Nothing new on the agenda, so 20:01:29 #topic open floor 20:01:39 #chair jborean93 20:01:39 Current chairs: jborean93 nitzmahone 20:02:14 👋hi everyone, working on another new module for configuring powershell remoting session configurations, should have a PR up in the next week or so 20:02:14 I think the docs team have decided on a changelog process for collections. Just waiting on the final decision and details to come out before migrating the existing 2.10 changelog fragments to each collection 20:02:39 briantist: noice, looking forward to seeing that 20:03:05 interested to see how you plan on bypassing the WinRM service restart requirement there 20:03:10 the action plugin that lets it avoid being killed by the winrm restart is nifty if I do say so myself 20:03:16 ah 20:03:18 cool 20:06:19 Welp, if nothing pressing, we'll close up in 2m. 20:06:24 jborean93: I ran into another instance of an async task having a weird failure related to registry unloading, put the details in that one ticket but not sure if you saw it 20:06:34 (^ that's not pressing, doesn't need to hold the meeting) 20:06:46 yea I did see that, haven't had time to look into it yet sorry 20:06:55 no worries 20:07:26 * nitzmahone still wants to get a 100% reliable repro on that one 20:07:56 it being related to roaming profiles or something would make sense. It was similar to what I saw when testing against Azure hosts in CI where it would sometimes fail until I logged on interactively to find out more what happened 20:08:19 If we can get something really easy, can probably engage MS to hopefully suggest a workaround 20:08:25 I can say it's not related to roaming profiles in my case as we don't use them 20:09:16 It seems to happen more on cloud hosts, which makes me suspect it's a race that's exacerbated on slow machines 20:09:38 especially with TiWorker thrashing those machines on first startup 20:09:43 Yep 20:09:49 (grr) 20:10:27 some of my previous repros were on long lived machines. Recent one is recent startup, but it only happens with 1 of the 2 users tried 20:10:38 and that same user, doesn't repro on other hosts 20:10:41 it reallyis baffling 20:10:55 I'm still betting there's some internal/pseudo-documented API we can use to add another ref to the profile handle 20:13:52 jborean93: can't remember, did you try this in your messings around on that? https://support.microsoft.com/en-us/help/2287297/a-com-application-may-stop-working-in-windows-when-a-user-logs-off 20:14:28 (the policy change to stop forced profile unloading) 20:14:47 no I don't think I did, it was quite some time ago 20:15:23 did we ever look into using powershell scheduled jobs as a mechanism for async? I remember seeing some code maybe in the windows update module that was using them, but wondering if it might make for a good general async solution 20:15:30 Weirdly I also remember a weird issue were using become on 2008 and 08 R2 would have the user's registry hive never unload which seems to be the opposite of the issue with async 20:15:59 briantist: you might want to try that if you've got some places it happens pretty regularly 20:16:00 nitzmahone wrote the original async using CreateProcess and the job breakaway flag 20:16:19 I wrote the current WMI based one due to some connections not allowing the process to breakaway from the job 20:16:54 plus become + async never worked until the WMI stuff on 2008 and 08 R2 20:17:12 I suspect this problem might also be lessened if/when we do persistent interpreter and/or connection 20:17:59 nitzmahone did you mean try the policy change? my latest repro was last week, I can see if it's still happening and see if the policy changes that 20:18:47 Anyway, wrapping up for today- till next week! 20:18:52 #endmeeting