20:00:00 <jborean93> #startmeeting Ansible Windows Working Group
20:00:00 <zodbot> Meeting started Tue Apr 12 20:00:00 2022 UTC.
20:00:00 <zodbot> This meeting is logged and archived in a public location.
20:00:00 <zodbot> The chair is jborean93. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:00 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:43 <jborean93> #info agenda https://github.com/ansible/community/issues/644
20:00:54 <jborean93> Nothing is on the agenda today so straight to the open floor
20:00:57 <jborean93> #topic open floor
20:02:42 <briantist> hello
20:03:04 <jborean93> hey
20:03:21 <jborean93> how's it going?
20:05:00 <briantist> not bad, been in contributor summit all day, and juggling work stuff too
20:05:02 <briantist> you?
20:05:46 <jborean93> just tired in general, can't wait for the long weekends that are coming up for me
20:08:56 <briantist> ahh that sounds nice
20:09:33 <briantist> I've been struggling with building an installer (MSI) for the CCG Plugin
20:10:01 <briantist> install works, uninstall works, but I keep running into issues during "repair" if it's running at the time
20:10:39 <jborean93> shouldn't packaged it as an MSIX :P
20:10:46 <jborean93> should've*
20:11:34 <briantist> hm I've never looked at that
20:12:19 <jborean93> I honestly don't know how it would work for this type of setup though
20:12:23 <briantist> but already I can see, it took a while to even add windows services support, don't see COM+ anywhere in there
20:12:31 <briantist> not that I'm surprised, but yeah...
20:12:45 <jborean93> Historically it was for UWP apps but they've slowly adding more support for older Win32 like applications
20:13:27 <jborean93> My only experience with building msi's are the dummy packages I created for the win_package integration tests
20:13:30 <briantist> part of the issue is that the COM+ support in WIX is broken for apps that use .net 4, so I can't even completely use it, but the partial working support is still helpful, it removes fine on uninstall
20:14:01 <nitzmahone> I definitely don't miss owning MSIs
20:14:27 <briantist> and COM+ apps can be installed as Windows services, but you have to do it within the COM+ system; like through the MMC app, or via the catalog APIs, WIX doesn't have support for that at all
20:14:28 <nitzmahone> (but WIX was a godsend compared to the dumpster fires of things like Installshield and others)
20:14:56 <briantist> so I've just implemented that (I mean I wanted to anyway, but was gonna put it off), in the hopes that WIX's Windows service support will be able to now just stop the service on repair...
20:15:04 <nitzmahone> You can also do it with just static registry stuff, but that's pretty brittle
20:15:26 <nitzmahone> (and it's a PITA if you need to run under a custom identity)
20:15:28 <briantist> just finished that a few miutes ago, but it still doesn't work, I think it's an ordering thing, it's checking if the file is in use before it even tries to stop the service
20:16:01 <briantist> WIX can handle registering services fine, so I don't need to the reg stuff, the problem is you can properly get the com+ app to work via service without doing it through the COM+ API
20:16:26 <briantist> I tried it; manually registering the service with all the same stuff, but it doesn't actually work unless you check the box in the COM+ side
20:17:03 <briantist> can't* get
20:18:02 <briantist> so now I  have the COM+ w/ NT service stuff working, but still can't get the timing right on repairs
20:18:05 <nitzmahone> It's been too long- most of my COM+ installer stuff was limited to the DCOM compat bits for LocalServer stuff, so I don't have any other ideas beyond rolling your own custom action or helper :(
20:18:44 <briantist> I think it's because I need to tie the service control bit in the MSI to the file that's locked, and right now I'm tying it to the COM+ element which comes later
20:19:06 <briantist> so during repair it checks for locked files before it ever reaches the service control part
20:19:28 <briantist> anyway.. I could go on and on about this.. but I won't
20:19:48 <briantist> it's just unreal how relatively easy it was to get install and uninstall working, but repair is killing me lol
20:23:34 <jborean93> yea, it's fun when things work but when it doesn't you have so many layers to unpack and debug
20:24:19 <jborean93> I thought I was going crazy trying to get cert auth working on a Github Action Runner, turns out I'm not the only one seeing issues with cert auth and Server 2022 https://github.com/ansible-collections/ansible.windows/issues/333
20:24:47 <briantist> there's been a lot of weird shit with server-2022 in GHA
20:26:08 <jborean93> I think this problem is Server 2022 specific and not just GHA but I know what you mean
20:26:58 <jborean93> My guess is the introduction of TLS 1.3 has broken something but I couldn't figure out the problem in the end
20:27:24 <jborean93> I was able to fix cert auth with a hosted IIS site by disabling HTTP 2 but the same method didn't work for the HTTPS WinRM listener
20:27:48 <briantist> right I figure some of it is not GHA-specific but haven't been able to determine where the line is just yet
20:28:04 <briantist> most of the things I've used server 2022 for locally have been fine
20:28:10 <jborean93> the lines moves depending on how it is feeling on the day it seems
20:28:48 <briantist> one team here compared deploying their service to 2022 vs their current 2016, and saw a solid 10% drop in performance, but unclear why
20:29:45 <jborean93> That is another problem I've seen with GHA testing and pypsrp. I'm not sure if it's 2022 specific but testing WSMan on localhost can just be really slow
20:30:17 <jborean93> I found that sometimes the slowness was caused by the `AWSPowerShell` module, removing it reduced a general loopback connection from 10 seconds to 1 in some cases
20:30:27 <jborean93> But even when doing that it is still quite slow in general
20:33:17 <briantist> interesting; that module takes a while to load, but I don't recall it causing any additional delays after loading (or maybe I just wasn't in a position to notice)
20:34:04 <jborean93> it wasn't loading but unloading that was a problem
20:34:52 <jborean93> For example doing `Invoke-Command localhost { whoami }` would run whoami pretty much straight away but powershell would take a while to exit
20:35:57 <briantist> ahhh
20:41:03 <jborean93> cool unless there's anything else I'll end the meeting
20:43:09 <jborean93> thanks everyone!
20:43:11 <jborean93> #endmeeting