Tom
Members-
Posts
25 -
Joined
-
Last visited
Reputation
15 GoodAbout Tom

-
I have had to also disable slow link detection (computer-system-group policy-configure slow link = enabled,0) in addition to setting the hardened UNC path values. I have pushed out the hardened unc values by GPO rather than by script/registry (it is in one of the windows 10 admx files), along with slow link disable. One reboot on the wire makes my wireless clients work again! - So doing it before domain join isn't necessary in my case. They are not logging anything about slow link (and gpresult always says it is not slow!), but setting it seems to be required anyway....
-
Nice one @themightymrp! - That appears to fix it! first reboot after setting those and it ran through all the computer policy settings including the software installs! I have just properly read your link which you posted right at the start of this thread. I wish I had read this all earlier! The way that it only seems to be affecting some models and not others had thrown me off. I'm back on site again tomorrow so I can try this live on all the windows 10 devices. It will be interesting to see if the slow link settings are also required or if they just 'mask' the URL hardening issue somehow for user GPO's. I shall stick the URL hardening settings in via registry from a USB stick, and then reboot some devices and see if they start picking everything up properly on the wireless. I was testing with a flat install of win10 edu x32 today direct from the install.wim on the CD. No windows updates installed. My other image had some more apps in and was updated up to last week.
-
I have reinstalled a couple of my devices and get them working on a test domain with minimal gpos and got the same issues. I've also installed some different tablets with the same windows 10 image and get the same problems. However, thanks @GuyJD - looks like it is slow link related. It isnt reporting a slow link in event viewer but fully disabling it by GPO (and then restarting them on a wire to get the new settings) seems to make user logon work properly and always apply the GPO's. I cannot however make it apply any of the computer GPO's over wireless. I have forced things like software installation on over a slow link in the same GPO. always just gives GPT.ini errors against the first GPO in the domain and then seems to give up. I think there are slow link detection issues with wireless connections in windows 10...
-
my devices are not properly processing the user GPO's every time either. Seems to always fail on the first logon after boot, most of the time on ones after that. flawless everytime when i plug a wire in! (and on other devices). Something wierd is going on as if I try to run the GP RSOP wizard on a machine that has failed GPO's I cant see the user logon to run it against. If I do an RSOP wizard after an on wire bootup and logon everything is there as expected.
-
I have looked at multiple DC's and cannot find a corrupt copy of this gpt.ini file. No other machines are complaining about it. I think this error is a consequence of some of these issues rather than the root cause of this problem. The GPO is on the root of the domain (and is the bottom one in the list when you do gpresult /r /scope:computer) - so it looks like it is the first one it should be applying. I am also seeing errors from WLAN-autoconfig in the system log that seem to happen on bootup just before the gpt.ini errors saying "WLAN extensibility module has failed to start c:\windows\system32\Rrlihvs.dll". I asssume this is part of the realtek wireless driver. Annoyingly I cant seem to un-install the current version of the driver so that I can go back to an older version (which has worked on many other drivers on this tablet) as it has no checkbox to uninstall the driver files! I am not on site to try this right now. Can somebody else give it a go? I do have a device offsite though and have checked. IIPv6 is enabled at the moment, but there is no wired lan interface on it (I have been using a USB dongle) so the wifi is top of the list above Remote Access Connections.
-
I put mine on max performance and it makes no difference. I am also seeing an error about a gpt.ini in the event log. Always seems to be one that is at the domain root. However other machines are getting it fine and it gives no error on the affected laptops when on a wire. I am getting some errors in the event log from the wireless card on these devices which don't seem to be happening on others. I had these tablets working perfectly on the wireless on monday - but they were missing some drivers. It is since the driver update that they have stopped working.
-
Im currently experiencing this on some linx tablets with win10 on. I think it is wireless driver related. These things were fine until I reinstalled a load of drivers to get other things working in device manager. I have other models of device with the same windows 10 image on and they are not experiencing it.
-
I've done hundreds of C50's since my last post!. They deploy at normal speeds for me. I am now using the windows 8.0 x32 boot image in WDS 2008/2012, and have option 66 set to the WDS server IP and option 67 set as above. I am putting windows 7.1 x32 images onto them
-
If anybody is still trying to get these stupid laptops to PXE boot, we have found the problem and a workaround for it and I have a support case open with Toshiba where they are replicating it which will hopefully lead to a proper fix. Amusingly this is taking a while since our laptops shipped to us with bios version 1.20 which hasn't been released to Toshiba UK support yet! The issue appears to be that the C50 isnt able to use more than one DHCP server for the boot process - so if you have a DHCP server giving out an IP and a seperate WDS server giving out the PXE options (60,66 and 67), it doesnt get the responses from the second server - so fails with the file not found error. If you have WDS on the same server as DHCP it works. You can specify options 66 and 67 on your main DHCP Scope and force it to work - set option 066 to your WDS Server IP address/FQDN and 067 with the following string "\boot\x86\wdsnbp.com". this will work for x32 boot images (win7 or win8) on wds 2008 and 2012. We have deployed win7 x32 onto ours quite happily. This issue is affecting 2 different 'sub-modles' of the C50 which we have - so don't buy any new ones without expecting it.
-
I think there are different sub-models (as with all the Toshes!). I also have C50-A-15Q's which come with windows 8 x64. They were supposed to be C850's but they went EOL before the order got there and somebody decided that these would be an equivalent replacement
-
I encountered these horrible laptops this week and ended up removing the HDD's to image in another PC. I have another 60 of them to do next week! would rather not have to remove them all to image! I couldnt even get them to boot from a USB stick with secure boot off & CSM on. didnt try forcing the boot order though. If you have wds2012 you can UEFI network boot them from a windows 8 x64 boot image - but then cant deploy x32 windows 7 images Andyase - Did you create your discover boot image from an x64 or x32 windows 7 boot.wim? I want to deploy an x32 windows 7 imstall image to these things.
-
Does anybody have the url for the ftp upgrade? they will only post out the CD now and i dont want to wait!
-
I've just fixed the problem in the OP thanks to this. Error started when i moved a sims server between domains. Deleting the My sims documents folder from my documents and letting it recreate it fixed it. Also, in addition to the originally described error where you cannot logon as a normal sims user, you can still logon to sims.net as SYSMAN, but when you go to tools-setups-document management server option it crashes here instead.
-
Cheers Tom, The support guy i spoke to was great! It turned out that it was an authentication issue, and either the people reporting it broken before i changed that were lying, or something else had happened to refresh the user accounts on my smoothwall before i added the new DC. I had got the VPN users in my domain in 2 AD groups which the smoothwall knew about, a std proxy one and a VPN allowed one. It used to pick up the VPN one in preference to the normal one, and thus auth them for the VPN connection. It was now picking them up as the normal group and failing them when they tried to VPN in. Have created some local user accounts for them to use just for VPN access and these work.
