Sheridan

Our goes through an unauthenticated proxy with meraki/apple whitelisted and not https inspection. Our smoothwall doesn't seem to be blocking anything, traffic from these devices goes through OK but obviously something isn't working somewhere.

So do yours hit a proxy in any way? Ours are directed to a proxy, but it still hits the firewall sometimes on some of the ports Meraki specify.

Mine still wont do the initial synch, nor download some apps once the initial synch is done over a hotspot connection. If you try the manual download of a missing app in the Meraki MDM app, it just stills spinning away yet nothing shows are being blocked on the firewall or smoothwall. Out of interest, what firewall exceptions are you running for Meraki? I've used the definitions from their site but I'm still not convinced our TMG isn't breaking this somehow as even a whitelisted devices doesn't synch through it anymore.

I did try that update on a few of the failing clients and it says its not applicable - these clients were bang up to date with updates as of mid August.

My current attempt is on Server 2012 R2, build of WSUS is 10.0.10514.4. Most are failing with the following error log in WindowsUpdate.log - as recent as this morning they are failing. I can't seem to find any way around this. 100% of our W7 clients were working until some point a few weeks ago when the WSUS server was P2V'd and from that point they won't connect to any WSUS server, which makes me think its a client fault now. I can download the iuident.cab from the client and also telnet from the client to the WSUS server on port 8530, but when I close the telnet connection I get an HTML error that may just be a red herring:

Yup we are using a smoothwall utm but it affect all users regardless of policy so I can't see what I could change!

Hmm sounds like I'm not alone. We have been using Meraki for a little while but don't have many devices on it - however with the firewall rules etc in place they have been enrolling and downloading apps OK. Until this last week or so. Now they will enroll (usually) but never perform their initial synchronisation - however if I hotspot them to a phone they do this stage and then start pulling the apps down. Not sure why as I've even tried letting them out through our TMG2010 firewall open on all ports outbound - nothing on the firewall logs shows anything being blocked. Even when they work, some apps are missing, some say they're missing but are installed. Some say 'Install application enqueued' in the console and it never changes. I'm getting such varied results I've forgotten where I started. This was our trail with meraki for a larger deployment and so far its proved that a) its not working for us anymore and b) meraki won't give you any support unless you're already paying! Off to trial lightspeed now I think!

I'm now on another brand new physical server, which has all of my clients showing, but only about 1/5 are reporting in. Theres no rhyme nor reason to the ones that are compared to the ones that aren't! They've all had their SUS ID reset to try and reconnect them and were all working fine until a few weeks ago!

We do use a proxy with exceptions for all local servers, but nothing has changed in that sense to cause all of our Wsus clients to fail. In fact the only thing that changed was I did a p2v of the server. I've since tried two new vms but they get the same result. If I hadn't wiped the old physical server I would have brought that back online!

Out of curiosity how did you deploy this? My Wsus clients register in the console but never report in so I'd have to use a GPO to dish this out.

Looks like TMG2010 doesn't like the way Meraki works now - I can see quite a few "A non-SYN packet was dropped because it was sent by a source that does not have an established connection with the Forefront TMG computer" errors when the clients are connecting.

The only time I had oddly slow copying of files across from a server was on some client where the NIC drivers needed updating. The drivers were pretty recent but updating to the very latest sorted out the handful that had the problem.

Its showing Verified for the Meraki profile - its sticking somewhere that won't let it enroll and pull down the profile. Edit: Mind you the Meraki firewall rules are garbage, watching the traffic from one of these ipads shows all sorts of activity on ports 80 and loads of ip addresses not in the Meraki ranges being accessed when trying to enroll

This is a puzzling one, still no ios devices will enroll. The enrollment procedure completes OK and the devices shows in the dashboard but never checks in. It must be a connectivity issue but our firewall shows the device connecting with no errors! This was a trial of meraki for future rollout of staff ipads so I guess lightspeed is the next option.

I'd seen something similar so I've already increased to limit on my server to 8gb. I've now gone back to Wsus 3.0 on Server 2008R2 and its still not working. Oddly though, I seem to have around 1/6th of the clients reporting in - the others have not yet reported in. Theres no logic to this as in a room of 30 PCs (all created from the same sysprep'd image and on the same hardware) I have maybe 3-4 reporting in!

We've been on the new one a good while and have had no problems. These two new iPads are iOS 9 and seem to connect but never enrol. If I look at the console of the iPad I can see 'iPad Meraki MDM' errors reporting 404. I assume that's http and page not found but not sure if meraki have changed anything?

Anyone else having issues with meraki? I've registed a good few devices in the last 12 months so I know our firewall settings are correct, yet 2 brand new ipads will not enroll, they just stick at the 'Waiting for enrollment' message I can see they are hitting the firewall, and being allowed through. But they will not enrol. They show up in the Meraki dashboard as 'never' connected and unmanaged. I've checked our firewall rules match those that meraki have specified (they haven't changed recently) so I'm a bit baffled!

I've managed to change the mail attribute for everyone now so I get a good synch test result! Only couple of issues I know will crop up are: 1) User title isn't in AD, so Mrs Smith will appear as Julie Smith etc - some might not like that! 2) We will lose the class sets groups from our current MIS, as the AD groups are manually created and don't pull from it. I know theres a Schools version of GADS, but that seems to involved exporting csvs and I want to make this as simple as possible! Other than that, so far so good!

Yeah I think an update to outr W7 clients has broken it, but I've yet to find out which one!

I can occasionally get the console working (using a restart or the /postinstall command) but my clients refuse to connect. I'm looking at a monthly batch of updates deployed by scripting now.

I set mine to port 80, so the connection is just to http://servername. It seems to be likely an update broke the update client on all of my windows 7 machines as they were quite happily updating from the original wsus server for about 2 years. All of a sudden they all stopped. I've tried Wsus on 2008r2 and 2012r2 and tried every reset/reinstall of the update client and settings on the affected PCs. Short of reimaging the clients I have nowhere else to look! Time to find an alternative as I've wasted so much time on this already.

Well, full reinstall of WSUS on a new server (again) and every single W7 client failing to update. All now logging: 2016-09-21 13:39:48:857 988 51c PT WARNING: GetCookie failure, error = 0x80244008, soap client error = 8, soap error code = 0, HTTP status code = 200 2016-09-21 13:39:48:857 988 51c PT WARNING: PTError: 0x80244008 2016-09-21 13:39:48:857 988 51c PT WARNING: GetCookie_WithRecovery failed : 0x80244008 2016-09-21 13:39:48:857 988 51c PT WARNING: RefreshCookie failed: 0x80244008 2016-09-21 13:39:48:857 988 51c PT WARNING: RefreshPTState failed: 0x80244008 2016-09-21 13:39:48:857 988 51c PT WARNING: PTError: 0x80244008 2016-09-21 13:39:48:857 988 51c Report WARNING: Reporter failed to upload events with hr = 80244008. I think the phrase is 'I'm stuffed' as searching for those error numbers doesn't offer anything that is a solution. So I'll have to find a way to manually download critical updates and push them out a different way as wsus looks like a dead duck for me. Is anyone else manually applying update like this?

I've run the cleanup wizard on the original WSUS server and it didn't help the client connectivity. I ran it on the new server and it only removed a handful of updates as the WSUS database will have been pretty clean anyway.

I can get the console up (for a period of time anyway) by restarting the server - it crashes out pretty quickly after that but not at any specific time. I can move wsus back to the 2008 R2 server as the console worked ok on that, the big problem is the clients not reporting. I know MS are pushing us to us W10 but the update mechanism in that is pretty unreliable with wsus as well! Each client logs the error 'Windows Update Client failed to detect with error 0x80244010' and I can't run the Update diagnostics tool as it generates another error: This does suggest an update killed WSUS at the client end.

Hmm,this is why I suspect a W7 update has broken something.