I found this forum (and especially this thread) because of memory-limitations to the 2008R2-Server. In my opinion it is very annoying that Microsoft has limited the Standard-Edition to 32GB - The same limit as it has been applied to the older "non-R2"-Server. Keep in mind that each "non-Home" Win7 allows accessing 192GB. Even Vista can take use of 128GB. But "Windows Server 2008R2 Standard" is limited to 32GB - That's a bad joke, isn't it? Okay ... this forum is not the right place to flame against Microsoft licensing-practice. I've signed up to this forum to address the "deactivating SPP-Service"-Problem (since I have not found a work-around for the desktop-watermark and nag-screens). After testing KOSTs great tool (many thanks! Especially for the SourceCode.) I have noticed that you do not need to deactivate SPP if you will need the new ProductPolicy for a single boot-time. On first boot after updating the Registry-Value, the Microsoft-Kernel reads the new Memory-Limit and applies this, even though the SPP will reset this value. Resetting this value will take affect after next boot-cycle. So here is my suggestion: If we could write a tool which would be placed in the machines master-boot-record, it should be possible to set the "right" ProductPolicy-RegistryValue (which can easily be composed by KOSTs tool) on each reboot before the Kernel accesses this value. Even if SPP would reset the value - This will not matter (at least for the memorylimit), since the kernel has already applied the faked ProductPolicy-RegistryValue. There are some caveats for this tool: Windows-Servers often are equipped with special RAID-Hardware, which cannot be accessed by standard AHCI- or IDE-Drivers. The tool must accept an appropriate RAID-driver. It will also have to support NTFS in RW-Mode (which most DOS-Application won't do). And the tool needs a configuration-interface (i.e. INI-Files) for pointing to the system's RegistyHive-Location and for specifying the faked ProductPolicy-RegistryValue. Any thoughts for my approach? Did I miss any unavoidable problems? PS: Please don't mind any bad English - I'm just German ;-)
maybe your right with certain policies that won't apply before the next restart but on some values any spp task will rewrite the protected registry value so that also this effect won't be online till the next restart. - indeed it may would be helpfull for especially server editions to write some kind of rootkit (like konboot or even daz loader) to apply settings the way you want but i guess there are not that much many people who are interessted in it (unfortunatly). and finally it all works with disabled spp services and tasks.
In fact I think this approach is not that special - Probably all Kernel-Values could be faked in this way without deactivating SPP ... So I think, that there would be some more interested people than me ... (I admit: this is very speculative ;-) BUT: I've got a solution for this! ... And this solution has always been here, since "kost" has shared his "Setup-Mode"-Knowledge with us! (I've just added another richly deserved "Thank" to "kost".) Use "kost"s PolicyEditor to create an appropriate RegKey Create a batch-File wich prepares Windows on every Boot to start in SetupMode next time Create a second batch-File, which will apply the RegKey (while being in SetupMode) and which does an auto-restart to finish SetupMode to automatically end up with your desktop That's a rough idea - I think I will be back with another post ... To supply a little "walkthrough" with suitable Batch-Files. At the moment I'm stuck in a special problem with my "Destination-Server": SetupMode works an all machines, except this server ... When using the SetupMode, I get the expected Boot-Screen, but no command-line pops up. I cannot use Shift-F10 or Ctrl+Shift+Esc. Only way out is: Doing Hardware-Reset Booting some Windows-Live-System Undoing Setup-Mode in Registry I think this could be due to RAID-Hardware, which is used by the Server. Another point making things more complicated: This RAID-Hardware was not present at 2008R2-Installation-Time - It was an upgrade. If 2008R2 stores some kind of "Repair-SystemRegistryHive" while doing the Server-Setup (as WinXP does in %windir%\repair) and SetupMode relies on this "Repair-Hive", there will be missing entries under HKLM\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase for the RAID-Hardware. I will have a closer look at all this during this weak ... And I will be back with more Info (hopefully with solutions ;-)
have you entered in cmdline value cmd.exe /k? or anything else as data? I've worked a lot with this key (all by hand) till kost was so nice to develop this small tool within a few hours. What you describe is my normal apply approach with some more spp related commands but in the end this doesn't matter. Also all you're raid concerons doesn't matter. If the system boots, the driver is loaded.
Regvalue "cmdline" has been set by ProductPolicyEditor. I've already thought about an inaccessible Path (because ProductPolicyEditor was placed on Admins Desktop). So I moved ProductPolicyEditor to a simple Path: "C:\1" and gave full permissions to all users. According to that, ProductPolicyEditor set Regkey "cmdline" to: cmd /k start "ppe" "C:\1\release\ProductPolicyEditor.exe" But I don't think that this Regvalue is the reason for my Problem: SetupMode hangs with the "Setup is preparing your computer for first use"-screen. CMD does not start and Regkey "SetupType" gets not reset to zero. I must admit, that this problem is probably not about RAID-Drivers. I initially thought of this problem, because normal Windows-Starts ends-up with BSOD (stop: 0x7b "inaccessible boot device") after showing Windows-Boot-Splash-Screen in such case. If (for some reasons) BSODs are not supported in SetupMode, it would be reaonable, that windows simply hangs at this moment. BUT: Meanwhile I have noticed, that even SetupMode begins with "normal" Windows-Boot-Splash-Screen, before switching to the "Setup is preparing ..."-Screen. I would expect the "inaccessible-boot-device"-stop before switching to the next screen (i.e. "Setup is preparing ..."-screen). But since swapping to the second screen works fine, I don't believe in a RAID-Driver-Problem anymore. I had a closer look at the Registry-Tree below "HKLM\System\Setup" and compared the Values of a Win7-Workstation (with working SetupMode) to the Values of the Server (with failing SetupMode). A significant difference is "HKLM\SYSTEM\Setup\AllowStart\NTDS". I assume that this value causes the Server to start AD-Services even in SetupMode. The Win7-Client does not have this value. I will give SetupMode a new chance after deleting this value. But I think it will take some time until I have another timeframe for shutting server down to do these tests.
Last tuesday I had a few hours to investigate the SetupType-Problem on my "Destination-Server" ... I'm still stuck with this problem - As mentioned above: This Windows2008R2-Server only shows the "Setup is preparing your Computer for first use"-screen, but no commandline gets involved. My approaches sum up as follows: Registry-Tree below HKLM\System\Setup on this Server differs from Win7-Workstations. For equalizing the Server's-Registry to the Registry of a Win7-Workstation, I've removed some keys with no success: HKLM\SYSTEM\Setup\AllowStart\NTDS HKLM\SYSTEM\Setup\AllowStart\sacsvr HKLM\SYSTEM\Setup\Service Reporting API\Baselines\1.0\0\ADFS HKLM\SYSTEM\Setup\Service Reporting API\Baselines\1.0\0\WSSEE HKLM\SYSTEM\Setup\Service Reporting API\Baselines\2.0\0\ADFS HKLM\SYSTEM\Setup\Service Reporting API\Baselines\2.0\0\WSSEE HKLM\SYSTEM\Setup\Service Reporting API\Baselines\2.0\1\ADFS HKLM\SYSTEM\Setup\Service Reporting API\Baselines\2.0\1\WSSEE I've tried different Device-Indexes for HKLM\System\Setup\SystemPartition="\Device\HarddiskVolume1" I wondered if my configuration has problems finding "cmd" (as specified in "HKLM\System\Setup\cmdline"). After trying a full-qualified path with no success, I've applied a wrong cmdline to a system which has no problems with SetupType=1: I noticed that Windows will exit SetupMode immediately by rebooting the system and resetting SetupMode to 0. My conclusion: If my server would have any difficulties by executing HKLM\System\Setup\cmdline, I would expect an automatic reboot - But my Server gets stuck in "Setup is preparing ..."-Screen. I've reinitialized WindowsUpdate (Catalogs/Database/...) to exclude problems with incompleted Updates which eventually interfere with SetupType (since some WindowsUpdates are based upon SetupType, too) I've tried SetupType=2 (instead of SetupType=1). There is not much documentation concerning this Registry-Switch ... My only Internet-findings were: SetupType=2 commits no reboot after finishing the cmdline-task. Using SetupType=2 on my 2008R2-Server finally starts the cmd !!!! At first sight, this seemed to be a success: My Batch-File could run in SetupType=2 and after manipulating Registry the Batch-File could commit the reboot itself. But then I've noticed, that there are more differences between SetupType=1 and =2: The ProducPolicy-RegistryValue is protected when using SetupType=2 (as this key is usually protected during OS-Executing). This protection is only deactivated while using SetupType=1. When having a look at URL social.technet.microsoft.com/Forums/de/itproxpsp/thread/b942a34d-c4a7-489c-bb01-45dd65fa9b20 I assume, that there are a lot more differences between SetupType=1 and =2 than committing an automatic reboot. In the end I'm still stuck - Any ideas? (Another idea came up yesterday: By executing compmgmt.msc at command-line while being in SetupType=1 I've noticed, that there are a lot of services which are running in Setup-Mode ... I want to compare the 2008R2-Services with a Win7-Workstation: Eventually there is a service which cannot startup in SetupType=1. Such a "broken service" could pervent cmdline form executing ... ?)
Firstly thanks for this software Personally I have tested the use of more than 2 physical processors with Windows 10 : Change Windows-Product-Policy : "Kernel-RegisteredProcessors" to 4 or more I also tested the activation of Cortana on Server 2016 : Change Windows-Product-Policy : "Cortana-AllowCortana-Enabled" to 1 And the 2 works perfectly
I tried to activate TSE/RDP with more than one simultaneous connection (Windows 10) by changing : TerminalServices-RemoteConnectionManager-AllowRemoteConnections=1 TerminalServices-RemoteConnectionManager-AllowMultipleSessions=1 TerminalServices-RemoteConnectionManager-AllowAppServerMode=1 TerminalServices-RemoteConnectionManager-AllowMultimon=1 TerminalServices-RemoteConnectionManager-MaxUserSessions=0 TerminalServices-RemoteConnectionManager-ce0ad219-4670-4988-98fb-89b14c2f072b-MaxSessions=0 TerminalServices-RemoteConnectionManager-45344fe7-00e6-4ac6-9f01-d01fd4ffadfb-MaxSessions=2 TerminalServices-RDP-7-Advanced-Compression-Allowed=1 TerminalServices-RemoteConnectionManager-45344fe7-00e6-4ac6-9f01-d01fd4ffadfb-LocalOnly=0 TerminalServices-RemoteConnectionManager-8dc86f1d-9969-4379-91c1-06fe1dc60575-MaxSessions=1000 TerminalServices-DeviceRedirection-Licenses-TSEasyPrintAllowed=1 TerminalServices-DeviceRedirection-Licenses-PnpRedirectionAllowed=1 TerminalServices-DeviceRedirection-Licenses-TSMFPluginAllowed=1 TerminalServices-RemoteConnectionManager-UiEffects-DWMRemotingAllowed=1 (rdpwrap.ini file from RDP Wrapper) but it does not work. I also tried taking server 2016 values but the same. EDIT : For fun I replaced all the "Windows Product Policy" of Windows 10 by those of Windows Server 2016:RDP works (2 simultaneous connections maxi) but I do not know what are "Product Policy" concerned....
Grrrrrr ! Office 2016 not working with SPP-Service disabled (Win 10) ... but enable SPP-Service after changed registry in "Setup-Mode" and restarting : it works. But I have to restart each time in "Setup-Mode" How automate this procedure ? - Restart alway in "Setup-Mode" - Change registry and reboot Can you help me create these batch-Files ? EDIT : Ok for Restart alway in "Setup-Mode" Just a batch file that changes at each stop/reboot : [HKEY_LOCAL_MACHINE\SYSTEM\Setup] "SetupType"=dword:00000001 But how to automate key change Kernel-RegisteredProcessors 4 in PPE And restart ??
Good News ! When shutting down the PC (with "Fast Startup" enabled), the "Windows Policies" are saved at the next startup. If [HKEY_LOCAL_MACHINE\SYSTEM\Setup] "SetupType"=dword:00000001 it does not take it into account: So it starts with SPP service enabled and "Windows Policies" changed. On the other hand if I restart it starts in "Setup Mode".
I have upgraded from Windows 10 1607 to 1703, and the "setup mode" no longer works ! [HKEY_LOCAL_MACHINE\SYSTEM\Setup] "SetupType"=dword:00000001 has no effect ... Does anyone have a solution ?
The productpolicyeditor is working for me on enterprise preview build 16237. I did have a problem with it booting back into the setup mode after making changes and exiting the cmd window, but I backed up the HKLM\System\Setup key beforehand, and restoring it allowed rebooting normally and all the changes I made persisted.
can you tell me where this "valid activation string in the long entry" option is? or what value I look for under the policy editor? thanks