stupid question: is there any way to change the license switch matrix? i think xinso had client win10 converted to server datacenter at some point
A reinstall for nothing, VS2017 works just fine on LTSB 1607. I just don't understand some people. Not supported doesn't mean it won't work. There is no problem with VS2017 on LTSB. Cheers. Edit: I've done a couple of Office 2019 installs on LTSB 1607 already, no issues at all.
In my experience, running Windows Server as a desktop OS is very Linux-like. With the full meaning of "Linux-like" The illusion and the temptation to make Windows Server into a Desktop, emerges when you open the Task Manager on a fresh install and see how amazingly lite the server OS seems! (Like Linux) As others have said, and I agree with, there are heaps of headaches that will crop up with drivers and applications refusing to run or install on a 'server' OS. There are almost always workarounds, but you end up chasing issues rather than using your PC---is this beginning to sound like our brother penguin lovers? As with Linux, you can reach a point where you've got everything running great! However, unlike Linux, if something suddenly goes bad, you don't have a large community to turn to. You will make new online friends! You'll spend a fair amount of time trolling threads talking to all the neck-beard server room guys. You'll learn a heap about Windows server OS. Maybe more than you want! Finally, the biggest downside--in my experience--is that, by the time you get everything working as you want with drivers and applications running smooth... you open Task Manger and it's no better than running a normal OS!! The illusion of 'lightness' has melted away! That's when you realize that maybe the regular Desktop OS isn't actually bloated after all. Now ... Having said all that ... I'm more than willing to be amazed!! I would love for someone to start a fresh thread where they map out step-by-step how they have successfully installed Windows Server 2109 as a desktop and made it run Autodesk Maya and Adobe Photoshop and all the required GPU drivers and games and everything working perfectly. And still start up using 500MB RAM and 1% CPU. This I want to see! Maybe Server 2019 is going to be different than all the others? Hope springs eternal!
I have not tested Optimize-Offline with LTSB, though I know many others have with positive results. I do have a version of Optimize-Offline that detects the LTSB flavor and processes specific optimizations for it accordingly, while omitting those that are not applicable. I have been meaning to migrate the two together but have been low on time with work and life, but I will get around to it this week. That said, may parameter processes in Optimize-Offline can be utilized across Windows 10 builds like Provisioned Application removals, System App removals, security enhancements, etc. Optimize-Offline is a mixture of a gentle and aggressive debloating automatic script that I update a few times per week (I'm actually working on a fairly major update now). Then it is run against multiple OS' across numerous system builds where we run stress tests on the final live products and I audit error logs directly from the devices running the script to my enterprise server in order to isolate any potential issues. In any case, I'm glad those of you using it are enjoying it...and the best is yet to come.
If you read the code of my script you will see it lacks any unnecessary bloat. Each process performs a specific function, and the script then uses previous processes to further optimize the OS, which removes the guess-work on what should be removed and reduces unnecessary bloat within the code itself. By using arrays, hashtables, logging, error monitoring and verifying that commands have committed without error, following processes can take that information and further perform optimizations specific to the previous optimizations processed. This prevents hack 'n slash builds and random removals because since the entire process is automated, it handles everything internally which eliminates potential user-error.
I think I looked at another version / script, because on a second quick glance I can say it's better than most s**t around the internet including my own My criticism was for such scripts in general - not using variables and just repeating text like a dumb command line dumper because idiots want everything verbose despite not understanding anything. But your script screams high quality effort and is actually quite slim by powershell "bloated by design" standards. Seriously, it's great! Sorry for any reputation denting (I guess you're used to it around here )
Go search the comments I have gotten just posting functions that do some nifty things. "How do I run this?" "It doesn't work." "Look at this error," etc. I do not have the time to babysit people and continually regurgitate the same info over-and-over. Moreover, 99% of the users are conditioned to use god-awful command-line scripts and will not deviate from such rubbish for significantly more advanced coding projects utilizing proper languages. I have a plethora of viable scripts, projects, GUIs, etc. that would be beneficial to the userbase. If you recall, I wrote an executable to convert an ISO/WIM to the full Pro for Workstations version a while back AT A USER'S REQUEST and because I wanted to help others who wanted to use Pro for Workstations. And yet even the .exe, which requires nothing more than dragging and dropping an image onto the executable, got a bunch of "How do I use this?" "It gives me a logging error," "Can I use it with Windows 7," etc. It was an executable that required nothing more than drag and drop (it's still on Github, actually). PowerShell, Java, Perl, C+ and C# (my primary coding languages) are not hard to use but expect the end-user to have some common sense. Conclusively, if people are truly interested in various projects I have then I'm more than willing to post them. And yes I did criticize MSMG toolkit because the way that script goes about performing a great majority of removals and debloating is completely lackadaisical and in many cases downright dangerous to a live system. Granted many do not know once booting their new OS up, I spent many an hour auditing logs from builds generated with that script (out of pure curiosity; not because I planned to use it) to my server with fairly poor results. I have found countless audit logs with the "STATUS_SXS_COMPONENT_STORE_CORRUPT" return error, which is invisible to the end-user but is a critical error that is detrimental to the functionality of Windows servicing and updating, and this error is almost always created by removing component packages forcefully (i.e. unhiding its registry key and then removing its corresponding packages). That is not how you remove component packages. Command-line DISM is not designed for that type of advanced core OS functionality removal - the DISM.API is because the API is able to allocate all packages all component structures into what is called a "heap." The DismMountImage function then maps the entire offline image contents to a dedicated and supported directory and then runs the DismOpenSession function allowing for the removal of packages with a final call to the DismDelete function. Then the changes are committed and the session is closed. Finally the image is unmounted and shut down with a copy of the original offline image isolated to the aforementioned dedicated directory. As such, while it performs these functions, it changes the permanency values of any component package from "permanent" to "removable." This is how I do core component removals with, for example, a project I have that will convert a Windows Server version into a desktop variation while maintaining the integrity of the server kernel and core components. This way users can not only have a working desktop, but also have access to server-specific components, security, networking, etc. Not to mention it's pretty well known across all coding repositories, development portals and coders themselves that incorporating a 3GB executable to aid in the functionality of your script is severely frowned upon. I'm talking about Toolkit Helper. My PfW executable is a tad over 1GB and uses C# code, utilizing the WimGapi.dll and a safe-handle class, to natively access the WIM file's handle where it can access and retrieve the XMDocument metadata of the image as well as calling the DISM.API to support any type of compression for reverse conversion (UUP-to-ISO and vice versa, ESD), header blob retrieval, full image expansion, the ability to modify a WIM using another WIM/ESD/etc. template to ensure integrity, offline registry hive control, full public and private namespace access, networking, the ability to mount an offline WIM within an offline WIM, on-the-fly image backups, etc. And I am not bragging here; simply pointing out the proper way things are done. If I tried to upload a script with an executable "helper" that is 3GB in size, PowerShellGet and Microsoft's Repository would delete my script before I finished its ReadMe. In conclusion, my purpose here is not to knock on other users' scripts because at the end of the day, they've spent a lot of time on them to make them do what the community wants, but if I had a nickle for the amount of private messages I get per week of people asking for advice and help after running some of these popular scripts, I could probably buy everyone here their own copy of SAPIEN PowerShell Studio 2019. As a footnote, abbodi's scripts always exude excellent code syntax, proper error handling and, from what I've seen, are pretty much 100% perfect in how they function and work. Abbodi is a programmer others should take note of in regards to functionality, usefulness and knowledge of how to create the best type of batch/cmd script possible with the least amount of bloat and no longevity issues. I could name others but I did not initially reply to this thread to have a p*ssing match, but hopefully I shed some light on supern00b's comment.
Although it might be possible (or at least look that way) personally i'd never recommend those types of Frankenbuilds. Better wait the ~2-3 weeks for the real deal.
Hey, man, no problem. I'm glad you found the script and I'm glad it's working well for you. As I said I have a fairly large update coming and the full GUI version will be coming soon, even if I have to forget about PowerShell 6 for the time being. Really all I have to do is write an XAML help file, which in itself will take quite a while. Not only because XAML is tedious and annoying, but because unlike the script on GitHub, the GUI offers a significant amount of advanced features and functions, and a handful will render a system completely inoperable (as in the device will be nothing more than a paperweight) if a user is too impatient to read or just haphazardly clicks around or blindly selects options because it "sounds cool" (like flashing the wrong BIOS to a board and bricking it). Since it's able to interact with the actual hardware of the device, beyond what Microsoft is able to do, and access OEM-designated namespaces, a user will be able to commit firmware changes from within Windows itself and without having to boot into the BIOS/UEFI to change things. This is only one of its features. I also created a full set of cmdlets for registry control since PowerShell's default cmdlets are absolute trash; users will be able to adjust their owner User Rights, Token Permissions, generated answer files with its built-in XML Writer, utilize the DISM.API for PROPER component and feature removal, incorporate features from more advanced OS flavors into client OS flavors (i.e. slipstreaming Win Servers GPO into a Windows 10, thus allowing for offline registry optimization where the changes made are reflect within Group Policy), bootcode transferring across networks or locally, VM creation, conversion and control. Full control over security hardware including TPM 1.2/TPM2/fTPM/Descrete TPM/Biometric devices/Virtual Smart Cards, CA certificate creation, full filesystem conversion without data loss, Security.Cryptography.CryptoStream, Security.Cryptography.PasswordDeriveBytes and Intersecting Vector Cryptology Hash and Salting for optimal secure passcodes and PINS, the exporting of an abundance of data to CVS or XML, including access control lists, integrating Metro Apps, Media Players, etc. into LTSB/Server, custom WinPE/WinRE creation, etc. etc. But as I said before, it does not have training wheels. It will have a thorough help file and about 5-6 people offering help on it but I, nor any of the others, will respond to the same dopey questions I get on here simply because certain people do not want to spend the 5 minutes to read.
Your Optimize-Offline script is free of bloat, but there are a couple trivial lines of duplicated code in the registry section of version 3.1.1.4: Under "Cleaning-up Windows Control Panel Links" Code: -Name "4" -Value "Microsoft.RegionAndLanguage" matches -Name "18" -Value "Microsoft.RegionAndLanguage" and the code block "Disabling System Tracking and Location Sensors." appears twice. Obviously, this duplicated code isn't 'hurting' anything, but I thought I would mention it. I imagine your probably having to maintain two code repositories? The PowerShell Optimize-Offline script and the GUI back-end script. I'm looking forward to applying all the advanced features and functions of the GUI version and hope you might have it ready to use on the upcoming LTSC 2019?!
This is why it helps to look at the newest versions and read the ChangeLog: ChangeLog Build 3.1.1.4 Removed redundant values for the hardened registry optimization parameter. Added the disabling of Windows' Advertising ID to the hardened registry optimization parameter. Added some additional error-catching Also the automatic application of the answer file, to improve the initial bootup, has been gone for about 2 versions now. Many because I did not want users who perhaps did not have any regional cmdlets to have $null valid timestamps. IIRC I found a few redundancies, albeit very small ones, as I worked through this latest update but I can't remember. When you have over 200 registry values, it can be hard to keep track of everything.