20:00:01 <nitzmahone> #startmeeting Ansible Windows Working Group
20:00:01 <zodbot> Meeting started Tue Aug  4 20:00:01 2020 UTC.
20:00:01 <zodbot> This meeting is logged and archived in a public location.
20:00:01 <zodbot> The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:01 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:09 <nitzmahone> bah, missed it by THAT much
20:00:10 <jhawkesworth> hey
20:00:15 <nitzmahone> Hey Jon!
20:00:22 <nitzmahone> #chair jborean93 jhawkesworth
20:00:22 <zodbot> Current chairs: jborean93 jhawkesworth nitzmahone
20:00:27 <jborean93> yo
20:00:37 <briantist> hey hey
20:00:46 <jhawkesworth> heya all
20:00:56 <nitzmahone> Hey briantist!
20:01:37 * nitzmahone was watching today's discussion about passing complex args to `win_shell` with bemusement
20:02:06 <nitzmahone> Easiest thing would probably be to just wrap the script in a custom Ansible module, since that already supports complex datatypes
20:02:28 * jhawkesworth scrolls back up
20:02:36 <briantist> if you go back another day or two you'll see we where Jordan and I recommended that several times
20:03:38 <nitzmahone> I was initially thinking "hey, it'd be neat if environment: supported complex types", but that wouldn't work very well for non-PS-native transports
20:03:42 <briantist> but I can sympathize somewhat with wanting not to use/maintain custom code; many teams are not set up to do that properly over time
20:03:58 <jborean93> they still have to use/maintain the custom code in win_shell
20:04:08 <jborean93> there's just a few extra lines of boilerplate that a module adds
20:04:23 <nitzmahone> It'd be possible to add sidecar complex args to win_shell, but not sure it's worth it
20:04:25 <jborean93> but subsequently removes when it comes to getting the input and formatting the output
20:04:32 <jborean93> I would be a -1 on that personally
20:04:41 <jhawkesworth> I still have a bunch of modules in my ansible config in library and I doubt rest of the team even know they are there
20:04:44 <jborean93> win_shell/win_command are based on text, you want to use arguments you need to serialize it
20:04:45 <briantist> yeah I agree, but that comes from a place of already having done it and being comfortable with it. I still remember being new to Ansible too ;)
20:05:23 <briantist> (above is re: a module just being some extra boilerplate)
20:06:09 * jhawkesworth feels bad about another win_xml issue (mentioned above).  I'll see if I can tackle that too
20:06:30 <jborean93> no need to feel bad, that module is a honeypot for complex problems like that
20:06:50 <briantist> I've also thought about an option of having Ansible.Module just being already available in `win_shell`; it would be nice sometimes to just be able to sort of have ad-hoc modules that don't need to be in their own file but support complex output (and maybe input) better
20:07:06 <briantist> I'm sure it does open several cans of various species of worms
20:07:16 <jhawkesworth> yep, makes me wonder why java world put up with it for so long
20:07:43 <nitzmahone> ... tis also why we didn't want to adopt it in core ;) - XML manipulation is snowflake enough that it's hard to figure out a set of features that would meet general needs
20:08:06 <nitzmahone> (see also: .NET's what, like 6th iteration of XML manipulation libs?)
20:08:49 <nitzmahone> Nothing on today's agenda BTW, so
20:08:52 <nitzmahone> #topic open floor
20:09:06 <jborean93> I was trying to debug a fun win_updates problem yesterday from the mailing list
20:09:18 <briantist> oh?
20:09:23 <jhawkesworth> yep, having worked on java-based soap services being consumed by .net clients there's a whole load of fun to be had even when both ends are dealing with valid xml
20:09:24 <nitzmahone> (for some value of "fun")
20:09:33 <jborean93> it looks like "optional" updates and win 10 feature packs are distributed by WUA , or at least I could never figure out how to find them
20:09:37 <jhawkesworth> oh yeah trying to install win 10 update versions
20:09:44 <jborean93> https://github.com/ansible-collections/ansible.windows/issues/87
20:09:47 <nitzmahone> was that "aren't"?
20:09:54 <jborean93> yea sorry
20:10:30 <jborean93> I can somewhat understand feature packs like the 2004 update as they aren't in the windows update catalog but optional updates like the cumulative previews are so I found it weird I could never get WUA to see them
20:10:34 <jhawkesworth> seems crazy that another mechanism would be used but...
20:10:44 <jborean93> it's all in the same UI as well :)
20:11:17 * nitzmahone wonders if maybe it's a new category GUID you have to ask for explicitly
20:11:26 <jborean93> nah I was filtering by nothing
20:11:28 <jhawkesworth> so at some point there was probably a windows update to windows update in order to support displaying optional updates.
20:11:34 <jborean93> and that's what we do in win_updates now
20:11:35 <briantist> wow. this is probably one of those things where it uses like the "xbox live chat engine" service or something and you never know until you try to disable the service and something else breaks
20:11:35 * jhawkesworth head explodes
20:11:48 <jborean93> the categories are filtered post search
20:11:50 <jhawkesworth> :-)
20:12:24 <nitzmahone> I could've sworn I ran into some cases where you *had* to send the category to the "server" to actually see them
20:12:27 <jborean93> the whole WUA is just plain weird and complex and based on idioms established in XP/2003 when it was a website running in IE
20:12:56 <nitzmahone> jborean93: have you tried seeing if any of those updates show up in WSUS?
20:13:15 <jborean93> I have not set one up so no
20:13:24 <jborean93> but based on internet posts they can be pushed out from there
20:13:43 <jborean93> for the cumulative preview I even tried filtering based on the GUID for the update and no luck
20:14:00 <jborean93> I couldn't try that for the feature pack because I couldn't find the GUID at all (because I couldn't find it in the catalog)
20:14:03 <nitzmahone> Would just be interesting to see if they show up in the normal sync categories and can be "seen" by WUA from WSUS instead of direct-to-MS
20:14:07 <jborean93> Even PSWindowsUpdates doesn't pick them up
20:14:27 <jborean93> I was using https://gist.github.com/jborean93/166f30af61e74ff1640662dfa4bccce6 to test it all out
20:14:34 <jhawkesworth> i know its possible to block optional updates somehow but quite how proprietary doing so is, I don't know
20:15:09 <jborean93> there's this whole servicingID thing that I don't fully understand but even the WUA logs do not show anything to do with the feature pack when it shows up in the GUI
20:15:16 <briantist> I would guess this all corresponds to when Microsoft changes to UsoClient and the associated service
20:17:05 <jborean93> the cumulative preview disappeared once I restarted the host so that could explain why I wasn't able to find it using the COM API (as it didn't apply anymore). But the feature pack is elusive
20:17:18 <jborean93> in any case it was a bit of a rabbit hole and just thought I would share my pain
20:17:53 <nitzmahone> IIUC though usoclient is still using the WU COM API under the covers, which is what we're using as well
20:17:56 <jhawkesworth> thanks for investigating, sorry I don't have any relevant experience
20:18:08 <nitzmahone> (easy enough to verify watching the logs)
20:18:27 <nitzmahone> Although yeah, maybe it's consulting an additional source or doing some other magic
20:18:50 <nitzmahone> My understanding was just that usoclient was supposed to replace the archiac wuauclt
20:18:58 <briantist> yeah, maybe split package types or something
20:19:05 <jborean93> still uses the archaic COM API :)
20:19:23 <nitzmahone> (which, TBF, still works pretty decently considering its age ;) )
20:20:00 <briantist> if it weren't for the new service (USoSvc or soemthing) I might agree it's just a CLI update. Could be wrong but it feels like new functionality was needed (probably in addition rather than replacing the COM lib)
20:22:01 <briantist> with a cursory search though I can't find any new programmatic interface though  :-/
20:23:16 <nitzmahone> Yeah, usually you can find random blog posts from MS folks talking about those kinds of changes, but I've never seen anything of any detail on that one
20:25:15 <nitzmahone> If nobody's got anything pressing, I'll close the meeting in 2min
20:25:22 <jhawkesworth> fwiw this page here https://www.tenforums.com/tutorials/76207-update-upgrade-windows-10-using-powershell.html seems to imply its possible using PSWindowsUpdate with -MicrosoftUpdate switch and some poking around with serviceid but I am totally looking at this from the outside
20:25:33 <jborean93> yea it says it's possible but it's not
20:25:52 <jhawkesworth> oh fun.  One of those
20:26:11 <jborean93> it also tells you to install the module under `C:\Windows\System32\WindowsPowerShell\v1.0\Modules` which no don't do that
20:26:21 <nitzmahone> :O
20:26:23 <jhawkesworth> sounds like the sort of thing that is rare therefore rarely tested therefore easily borked without being noticed
20:26:30 <jhawkesworth> ouch
20:26:36 <jborean93> yea, it could also be a newer change in the recent feature packs
20:26:52 <jborean93> I cam across some reddit posts that have the same issue I did but no resolution
20:27:09 <jborean93> or were focused around the insider build updates
20:29:20 <nitzmahone> We can keep geeking about Windows Update internals, I'm just gonna close out the meeting before I forget... Until next week!
20:29:22 <nitzmahone> #endmeeting