The patched termsrv.dll is essentially acting as a single session terminal server. The Administrator is allowed two sessions: a local (console) Administrator and a remote (terminal) Administrator. The remote Admin is essentially transient.
The thread on LTSC 2019 suggests that would not be possible, unless someone has written a revised vlmcsd.kmd. But there is no harm in trying to activate LTSC using ATM or the gVLK (if one exists) from LTSB. Trial and mostly error is the order of the day. The guy who develops VLMCSD says a new release is imminent. It's amazing what can be achieved with DISM, install_wim_tweak, ATM (and/or VLMCSD) with Windows 10 Enterprise.
Hello mates, Any one can patch termsrv.dll 10.0.14393.2457 (x64)? As RPDwrapper released the patch,but I can't patch the file manually as I did before.Or How can find the desired offset and patch it? Thank You
Use the excellent RDPWrap - rdpwrap.ini has recently been updated. @bjf2000 I always disable/remove Cortana when I install Windows Enterprise. So, when initiating a RDP session (using patched termsrv.dll 10.0.17763.1) I never experienced the OOBE set-up; but I did a delay. Cortana now seems to be an integral part of Windows. Apart from creating all the RDP accounts and then disabling Cortana; sysprep is the best way forward. Windows VD (Windows Tertiary Syphilis - TS, would be a better and more apt name) is also a decent alternative. Only an over/ill-educated Microsoft imbecile with an off the scale IQ could have come up with such an approriate moniker. Pretty please MIcrosoft reinstate Enterprise's gonads; or alternatively, embark on a mission to Mars and take your source code with you.
Try this 10.0.14393.2457 x64 termsrv.dll: BB01000000C7 =====> BB00000000C7 7418488D15E6 =====> EB18488D15E6 39813C0600000F84E9DC0200 =====> B80001000089813806000090 If that does not work, the issue will be addressed when I apply the respective service pack to a computer. ==== The RDP session initiation/OOBE problem was solved by the following reg file: === Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE] "HideOnlineAccountScreens"=dword:00000001 "HideEULAPage"=dword:00000001 "SkipMachineOOBE"=dword:00000001 "UnattendEnableRetailDemo"=dword:00000000 "HideOEMRegistrationScreen"=dword:00000001 "HideWirelessSetupInOOBE"=dword:00000001 "ProtectYourPC"=dword:00000003 "SkipUserOOBE"=dword:00000001 ==== Technically, the Skip*OOBE entries (perhaps the only ones that are actually required) have been deprecated; but, they appear to work: applied the file to an afflicted machine and now everything is just right! Bye. .
@Prince_Charles, just to follow up on my earlier profile-losing experiences with only doing B80001000089813806000090 instead of it plus 8B8058000000FF1597, the problem didn't recur once I reverted to NO patch (thankfully). In limited testing later with both changes in effect, the issue also hasn't recurred, so it probably won't. Question: What is the purpose of the one-byte-changed 8B8058000000FF1597? If this result proves out, it's a little mind-boggling that one byte could make for such a dramatic difference.
It is the "SingleUserOffset" (in Binarymaster's terminology); basically, it transforms (in conjunction with the main patch) Windows Enterprise 10.17763.1 into a Terminal Server. You may ask why is that significant? Well, it's because that 1 bit change enables the possibility of a dual administrator session, and hence multiple unique single sessions. Binarymaster's RDPWrap is simply brilliant: he stalls RDP sessions and hooks his SL policies. When termsrv.dll is physically patched you are at the mercy of the underlying SL polices, hence why I always state Windows Enterprise. Windows product policy is best described as the most vulgar term for female genitalia, and has yet to be penetrated. Binarymaster's RDPWrap functions perfectly with his SingleUserOffset.x64 value for 10.17763.1; but, when I physically patch termsrv.dll with RDPWrap's value it is not possible to obtain the dual administrator session. When I substitute my SingleUserOffset.x64 into RDPWrap, as I have previously mentioned, everything functions correctly. Why the sudden disparity? Microsoft has effectively downgraded (via SL polices) Windows Enterprise in order to obtain filthy lucre from Windows VD - the Corporate welfare queens of the world will not bat an eyelid; they will simply ask Donald for a tax break financed by reducing the remuneration of those in penal servitude! RDPWrap is now the preferred solution; but, if a user is content with single sessions, and slightly paranoid, an adequately patched termsrv.dll is more than adequate: I actually use both! So, to actually answer your question: it is not a one byte change, it is a bit change! It is the difference, so to speak, between a human and an ape - and given the fact that no ape has ever carpet bombed Dresden, or held human beings in sub-human bondage, is probably not a good comparison.
I am on Win 10 1803 and got everything working with the cracked termsrv.dll i want to update to 1809, last time i updated i faced issue with printers and users sessions whenever a user locked his session and try to log in again the rdp generated a new session for the user. so the user will be logged in twice. Can someone advies if this solved with the rdpwrap or the patched termsrv.dll ? Thank you
Ive been reading this post, i've noticed there are two options patched termsrv.dll and rdpwrap. which one to use for multiple remote users ? i think the rdpwrap. i've seen this solutions, [10.0.17763.1] LocalOnlyPatch.x64=1 LocalOnlyOffset.x64=77941 LocalOnlyCode.x64=jmpshort SingleUserPatch.x64=1 SingleUserOffset.x64=132F9 SingleUserCode.x64=Zero DefPolicyPatch.x64=1 DefPolicyOffset.x64=17F45 DefPolicyCode.x64=CDefPolicy_Query_eax_rcx SLInitHook.x64=1 SLInitOffset.x64=1ABFC SLInitFunc.x64=New_CSLQuery_Initialize [10.0.17763.1-SLInit] bInitialized.x64 =ECAB0 bServerSku.x64 =ECAB4 lMaxUserSessions.x64 =ECAB8 bAppServerAllowed.x64 =ECAC0 bRemoteConnAllowed.x64=ECAC4 bMultimonAllowed.x64 =ECAC8 ulMaxDebugSessions.x64=ECACC bFUSEnabled.x64 =ECAD0 Do we have to add this at the button of rdpwrap.ini file ? what about the exisiting info that is below the line starts with [10.0.17763.1-SLInit]. do i have to remove this and replace it with the new one ?
You didn't check...they're the same. That's normal for the shorter ones, but definitely not for the other. https://forums.mydigitallife.net/th...ermsrv-dll-patching.57102/page-4#post-1467299
One specific version of it does, but there are server requirements, among other things. It's no panacea for the likes of us.
If you install the business edition of 17763 from ISO, you'll see "Windows 10 Enterprise for Virtual Desktops" near or at the bottom of the list of editions. You'll be able to connect up to it multiple times, no problem, but ultimately licensing is involved. Perhaps someone around here has worked around it.