Guys I would not worry too much about the tracking stuff changing all that much. I'm making an inherent presumption that it is the one piece which won't change because hey you need that to be stable in order to do proper error correction along with feedback. That being said we still check to see if the changes made for each build still work with the script we are using to turn off the feedback. This will make it likely that it will work on builds that come out in the future.
Ok to carry on. I'm going to keep both the cmd and Powershell scripts synced up script wise. That means each change made to the powershell full disable / full enable will trickle down to the cmd script. It will mean script wise very little changes as a whole meaning its going from: W10TP build 9841 Telemetry disable/enable prototype v3 script -deagles and murphy78 --> W10TP build 9841 Telemetry disable/enable prototype v0.03 script -deagles and murphy78 This will make it easy to discern how they are in the prototype phase .
Both Scripts have been uploaded and are on the OP. -Script Change Log- -Scripts are now in sync on features for the Full Enable / Full Disable -Added Windows Event Collector to services stopped -Added Windows Event Log to services stopped -Power Shell Change Log- -Added Script to Kill Service without reboot -Added Gui functions to not resize from 380 by 175 -Added Lite Functionality to kill only Services (Kill the uploader) -Created boundaries to differentiate between button functions in the GUI We'll continue tinkering with the Full Disable functions on the Powershell script and CMD script. I want a full disable / enable.
That is singularly (not plural) the most ridiculous (and stupid) question I have ever been asked on this forum (as I'm on many). In the original post it states that each script is in the prototype phase as is the Operating System in question. That means each is being tested for stability on a non-stable Operating System. Neither of these scripts should be tested in a real environment aka outside of a testing environment. Let me be clear at the present time. We are testing the functionality of a script to disable the feedback system on an Operating System which is even out of Alpha Development. You accept all risks incurred when testing such an Operating system. I will not make this any more clear in that regard. If you are testing a script which is meant for an Operating System in Alpha Development then neither should be used in the real world. I'll make it even more transparent. I have been on this forum and seen a lot in terms of stupidity and this currently take top prize for stupid. Good Day
@say-no-to-data-mining: I'll assert this once: This is not a drama thread. Opinions are welcome in this thread so long as they pertain to something that is being experimented with/worked on. Talking about yourself in general or defending your opinions are just unimportant. We would kindly prefer that you refrain from these actions so that we can keep the thread relatively clear from idle talk to help us focus on the task at hand. I'll ask you nicely: Can you please discuss your feelings in another thread?
We don't know. I've been busy with integration since tuesday and now with all these esd files we need to get for the new build. You're welcome to try it and load a network monitoring program and test it for yourself.
The scripts have not been tested on Windows 10 build 9860. It should work based on the registry entries not changing. At the very least the lite enable / lite disable should work regardless of the Windows 10 build as it just targets the services. Let me be clear we do not want to do permanent changes to the OS so we can undo those changes. Basically the current idea is to do and in-depth disable for Windows 10 while having a script that does a lite job so that it works regardless of the Windows 10 build. At the moment I don't plan on changing the cmd script to add a lite option but will change the powershell script so we have two ways to do it. Is there any demand to add a service option (lite option) for the cmd script?
since this is a Technical Preview and is really not meant for everyday use one can assume the scripts are only meant for use in such a way. for those who insist on running it for everyday use i have one suggestion, install it, try it out, and if it breaks something, you were warned. if your looking for guarantees, there are none. i'm sure SMorgan and Murphy78 have tested their scripts to the best of their there ability, but again there are no guarantees. they are not privy to all the OS internals. i wrote a script that disables all the services without restart, and on restart ungreys the dmwappushsvc service buttons so they can be turned on or off at will, but as Murphy78 pointed out the other day, my method was flawed. the reason being is because, like doctors, we shall do no harm. all changes made have to be able to be undone, so when a new build comes out the OS will be in a like new state, the new build can be installed, and the script can be reapplied. to see if anything has changed. anyways, i had to spend the day redoing mine, so everything can be undone. i wrote it, i tested it, retested it, and that is the only way to know if something does what you want it to do. so let's say this. install in a VM, write a script, test it, and give yourself that guarantee your looking for.
lol! i was doing all my edits manually and finally decided to try writing a script. much easier ( not the script writing part ). thank go for google. the only part i had problem with was changing some binary data in one of the keys ( the data that controls the buttons ) took a while to figure out how to delete a few bits or bytes or whatever they're called. anyways i'm learning and it been fun. tiring but fun.
Never do something more than you need to. Tweaks in the registry require you to take the time to look through it. If you can make a script to do the edits for you then you really really should. Take a look at the OEM pack thread which will give you the usual tweaks that are done to Windows What else do we want to do with the Tracker scripts? I feel at this point they are more than ready to do testing on Windows 10.
that's all i've been doing since last friday. making a list of all the things i needed to do, but i was doing them manually. time consuming as you said that's what i started at about 4AM yesterday morning and finished (mostly) early this morning. the reason i started it was 1) to save time in the edits, 2) learn a little bit about scripting, and 3) get the service to stop without a restart because everyone said the only way to do it was to disable it, which does require a restart. now i can start and stop it without a restart. and when i do finally decide to restart it, i can start and stop it at will using services.msc. like you i'm curious and once i get something in my mind it stays with me until i solve it or find for myself it can't be solved. tweaks were never part of my thought process. although your suggestion is a good one, i know all of the tweaks i like to apply and have been doing them ( not the same tweaks ) since Windows 95. and before that tweaking settings in Dos boot files to get the best of what little memory we had. yours is definitely ready for testing, and if you thought i was saying that it wasn't, i apologize. i tried 1.09 and it worked great. haven't looked at 1.10 yet, but i'm sure it's even better. i just wanted to try doing things a little differently and learn a little in the process.
I started putting the scripts I used into a tweaks.bat file to load with an OEM pack so I don't have to do them anymore. They are done automatically. Currently we are on version 0.11 as I took the 1.0 off because its an alpha script with an alpha OS. It will now do a windows version query to determine if the script is running on Windows 10. If it is not running on Windows 10 both scripts will auto quit without changes. I'm going to look into adding the WMI functionality into the script which is going to require a restart because it targets some functionality without killing the wmi. Though now that I'm thinking about it I could restart the wmi service to get the tweaks applied to it without doing a full restart. The other alternative is to crash the Explorer ui as that always gets registry edits to be applied immediately lol I think we should make this work on the OS automatically. What I mean by that is that we should have the ability to selectively turn off key functions on the OS in terms of telemetry. We could do it by making a switch inside the OS in the start menu to silently turn the Telemetry on n off. It would be neat to be able to do that. That way we can test the functionality of tweaks that do not require reboots.
Sorry long day yesterday. I see what ya mean also saw that 0.0.0.0 is indeed faster to use. Ok I'll go ahead and do this real quick.