Termsrv.Dll Crack
Feb 2, 2015 - OK, I have it working. The problem of course was the ini file. I have used a lot of programs that have line numbers in the ini files and so it didn't.
There are many web sites outlining how to reconfigure windows XP, Vista, and Windows 7 to allow multiple concurrent Remote Desktop Sessions, basically making a desktop PC a terminal server. On many occasions I have pointed out doing so is a licensing violation, however I confess I have never seen this specifically stated in any ELUA. I have been privy to discussions with Microsoft where this has been discussed, and Microsoft employees and support site personnel have often posted it is not permitted on various sites.
Having been asked to verify this I reviewed various EULAs (End User Licensing Agreements) and it seems Microsoft more often explains in detail what is allowed than what us not. Much like your insurance company doesn’t state in your home owners policy you are not permitted to have bonfires in your basement.
Some ELUAs such the one for Windows 7 mentions; “The single primary user of the licensed computer may access a session from any other device using Remote Desktop”, but does not state you can have multiple sessions. It does however state you can have multiple users sharing a single session using NetMeeting or Remote Assistance, which means both users are sharing the same desktop and application, not separate sessions. The intent with this is to assist an end user. The modification is promoted as a patch, but a patch would be provided by Microsoft. This ‘patch’ was created by someone named DeepXW who on their own web page refers to it as “Crack termsrv.dll, remove the Concurrent Remote Desktop sessions limit”.
Most of the reputable sites explaining the hack also include a disclaimer explaining it is a violation. I have posted some examples at the end of my ramblings. Sites such as have even banned posting the hack as they have confirmed it is a licensing violation. We also need to consider if this hack were legal, you would also require buying RDP/RDS CALs (Client Access Licenses), and if Office were installed you would only be legit if you purchased volume licensing with one license for each user.
The latter two are requirements on any multi-session Microsoft O/S. The Office 2013 ELUA does clearly state that you cannot have multiple sessions: “Remote access. The user that primarily uses the licensed computer is the “primary user.” The primary user may access and use the software installed on the licensed device remotely from any other device, as long as the software installed on the licensed device is not being used non-remotely by another user simultaneously.” This same issue applies to third party software which in many cases has the same limitations. Granted the hack does work, with some occasional Winsock issues, and though the chances of being caught are minimal, if discovered in a Microsoft audit, which does happen, the penalties are stiff. I strongly encourage folk to approach this in a more secure, manageable, and legitimate way by using a Microsoft Remote Desktop Services Server (formerly called Terminal server). Sample comments from various sites outlining the hack: However, be warned.
Before you begin, I need to warn you that patching the file and allowing more than one concurrent Remote Desktop session will violate a few lines in the Windows XP EULA. Proceed with caution and at your own risk. I shall not be liable for any damage caused to you, your computer, your data or your dog/cat because of this. From Desktop, which basically only allows the single primary user of the licensed computer to access a session of the computer.
And that essentially tells us that the trick we revealed to enable multiple concurrent user in remote desktop in Windows 7 isn’t a legally licensed, despite that it’s really a good useful hack. From A quick note: enabling multiple concurrent RDP users may be against the Windows 7 End User Licensing Agreement (EULA). Please be sure to check the EULA beforehand and know that we do not recommend making these changes in cases where they may violate the EULA. From Regardless of what solution you come up with, concurrent desktop access (if you are not sharing a single session) is in violation of the desktop Windows EULA. Server 2012 has a new Remote Desktop Services (RDS) feature set which is a great addition to any network. A common reason for wanting to implement 2012 RDS is for the feature, RDP on steroids, which provides substantially better performance when remotely running graphic intensive applications, but there are other Remote FX as well, in addition to other Remote FX was included with Server 2008 R2, but the pre 2012 were more restrictive, and configuration was a little more involved.
Remote Desktop Services is installed a little differently than it’s predecessor Terminal Services. Most current instruction sets advise you to use the “Remote Desktop Services installation” wizard, seen in the third image below. However this automatically installs related services that conflict with those already installed on SBS, such as the Remote Desktop Gateway Service. Therefore you need to install using the “Role Based or feature-based installation” method and manually select the features to be installed.
Installation: To add a Server 2012, running the RDS role, the steps are as follows. Install the basic Server 2012 operating system. This can be on either a physical or virtual machine. Next join the computer to the domain.
Where this is an SBS domain you want to do this for obvious reasons, but just to note; Server 2012 RDS does require it be domain joined. To do so open the Server Manager Dashboard, click on “local server”, in the window to the right click on “Workgroup”, in the resulting window click “Change” and then select “Domain” and enter your internal domain name, such as MyDomain.local. Once completed and you have reboot the server, I recommend installing all Windows updates.
You can now begin the RDS installation. Make sure you have first logged in with a Domain Admin account and not a local administrator account.
First from the Server Manager Dashboard select “Add roles and features”. Next, as mentioned earlier, choose “Role Based or feature-based installation”. Select the local server.
Select the “Remote Desktop Service” role and click next. Do not select anything in the Features window, click next. There will be a pop-up window where you can select the RDS features you wish to install.
Select only the “Remote Desktop Session Host” option. You may also want to add the “Remote Desktop Licensing” service, though you can do so at a another time. The Licensing service will be discussed a little later on.
Click next. Click Add Features. Select restart the server automatically, and choose install. After a reboot the RDS service should be installed.
Tweak and configure access There are some minor configurations to be done as well. Computer OU: Firstly, on the SBS, in Active Directory Users and Computers (ADUC) you should move the new server from the Computer OU to the MyBusiness Computers SBSServers OU. This will allow it to show up in the Windows SBS Console under the Computers tab (it may take a few minutes to show up).
I usually create a sub-OU for Terminal Servers when applying group policies, but this is by no means necessary. User Group: Users must be granted the right to “log on though Remote Desktop Services”. To do so they need to be added to the local Remote Desktop Users” group on the RDS server, not the SBS.
It would not be convenient to manage this from the RDS server, adding one user at a time so it is best in ADUC on the SBS to add a new Security Group named something like “Terminal Server Users”. Then on the RDS server, under Administrative Tools Computer Management Local Users and Groups Groups, add this domain group to the local Remote Desktop Users group. This way from the SBS you can centrally manage by simply adding users to your new Terminal servers user group. RWW / RWA: You will also want to make the new RDS server available through Remote Web workplace / Remote Web Access. If added to the proper OU above it will be by default with SBS 2008, however with SBS 2011 you need to add a registry key. The following link explains: Note, that this does not apply to Server Essentials.
Certificate: Accessing the RDS server through RWA or using the RDP client and RD Gateway requires an SSL certificate. Where you are adding this to an SBS domain, access will use your existing certificate. Should you need to add a certificate, please see:. Router Configuration: Traditionally Terminal Services required forwarding port 3389 from the router to the Terminal server’s IP. SBS makes use of the Remote Desktop Gateway service and allows you to connect directly to the RDS server more securely using SSL and port 443.
This does require that port 443 be forwarded to the SBS, but presumably this is already configured if you are using OWA, RWA, and/or Sharepoint. RDP client: To access using the RDP client simply enter the RDS server’s name in the “Computer” box, and your SBS site’s FQDN in the RD Gateway server name box, under advanced settings. Licensing. RDS also requires a CAL (Client Access License) be assigned to each device or user in order to use Remote Desktop Services. This is managed with the Remote Desktop Licensing service mentioned earlier. There is a 120 day grace period before you are required to install the Licensing service, purchase, and add your CAL’s. If you exceed the 120 day grace period, users will be blocked from accessing the RDS server.
The service can be installed on an another similar vintage server in the domain, but for simplicity the following steps installs on the same server. If not already done, It is installed by running the Add Roles wizard in Server Manager, in the Add Roles window, expand Remote Desktop Services, select the Remote Desktop Licensing service, then complete the wizard.
Open the RD Licensing manager, located under Administrative Tools Remote Desktop services. Expand All servers, right click on your server, choose Activate Server, and complete the required company information fields.
The last step will let you add your CAL’s now, but I recommend waiting until completing your configuration. Right click on the server and choose “Review Configuration”. You may need to add the licensing server to the appropriate group in ADUC.
You can do so easily by clicking the Add to Group button. Licensing mode: CAL’s can be purchased as Per Device or Per User. The latter tends to be more common. A single Per User CAL allows one user to connect from as many devices as they like; office PC, home PC, hotel lobby PC, laptop, etc. A per Device CAL allows many users to connect from only one device.
The latter is generally only used in situations similar to a call center. Though you can mix User and Device CAL’s it is best to pick one or the other.
To set the licensing mode, open the local security policy by entering gpedit.msc in the Run box. Locate the following policy, enable, and set the licensing mode. Computer Configuration Administrative Templates Windows Components Remote Desktop Services Remote Desktop Session Host Licensing Set the Remote Desktop licensing mode. If you run the RD Licensing Diagnoser under Administrative Tools Remote Desktop services, and it states a licensing server has not been specified, you may also have to manually enter the server’s name in the local security policy.
It is located in the same place as the policy in the last step and named “Use the specified Remote Desktop license servers”. Server CAL’s: The discussion so far relates to RDS CAL’s but it should be noted that any user accessing any server on the network also requires Server CAL’s. Accessing the SBS and any other server of the same version year or older is covered by SBS CAL’s. Anyone accessing the new 2012 Server will also need Server 2012 CA’s in addition to SBS CAL’s. Firewall.
You may also have to edit the Windows firewall. Exceptions should automatically be created but on occasion they are not. You can verify and edit by using Control Panel Windows Firewall Allow an app or feature through the windows Firewall, and compare to the following screen shot. It seems to be the Remote Desktop Services Public setting that is not always enabled. Your RDS server should now be fully functional. I recently posted an article entitled “” which uses the GUI, a very lengthy process, but perhaps easier to understand for those not familiar with the Cisco Command Line Interface (CLI) like me.
However, I did promise to also post the handful of necessary commands to achieve the same thing using the command line. Please find the matching commands below using the same options and sample IP’s as in the previous post. You may wish to review the previous article should you require an explanation of why the various command are necessary. Note: this was done using ASA Version 8.2(5).
Following is an outline as to how to configure a Cisco ASA 5505 for an SBS 2008/2011 network, including basic router configurations, IP addressing, and port forwarding, using the GUI/ASDM. The ASDM version used at the time of writing is 6.4(5), and ASA Version 8.2(5). For the record this can be accomplished much more easily from the CLI/Command Line Interface, but we SBS folk tend to like to do things from a GUI. I will however post a follow-up article outlining how to do so from the CLI, using only a handful of commands.
Updte: for CLI instructions see: It is assumed the ASA is still set to factory defaults. If so, skip to “Basic Router configuration”. Reset to factory defaults: Since this article is dedicated to using the ASDM console, to reset from within, simply log on, select “File” from the menu, and then “Reset Device to the Factory Default Configuration”. If you do not have access to the ASDM console, i.e. You do not know the IP, you can use the blue console cable and access through Telnet. Once connected to the CLI (Command Line Interface) enter the following commands:.
enable. config t. config factory-default (press the space bar a few times when “more” is displayed to get back to the prompt). reload save-config noconfirm (to write to flash memory). the unit will reboot with factory defaults Basic Router configuration: We will run the Start up Wizard to do the basic configuration. During the process do not make changes to the internal interface IP or Internal DHCP settings.
Launch the ASDM using, choose to ignore the certificate error, and select “run Startup Wizard”. When prompted for a username and password leave both blank. You can also start the wizard from within the ASDM from the menu under Wizards, Startup Wizard. Edit: In case it is confusing; after publishing it was pointed out you can see the 192.168.111.254 current ASA address in the title bar.
Please ignore, it is unrelated to the configuration. Starting Point: In the first window accept the default “modify existing configuration” and click next.
Basic Configuration: If you like you can change the ASA Host Name and domain, but I is not necessary. I strongly recommend changing the password, and make it secure. When you log back in later the user name will still be blank. Interface Section: Leave all a defaults. Switch Port Allocation: Again the defaults are fine for this configuration. Interface IP Address Configuration: Presumably you have been assigned a static public IP by your ISP where you are running a mail server. If so select “Use the following IP address”, enter the appropriate IP and subnet mask under “Outside Address”.
(Note: you will need to add a static route for the default gateway later) If using DHCP with your ISP, select “Use DHCP” and check “Obtain default route using DHCP” (which will automatically add the default gateway). When using DHCP you will probably also want to set up a DDNS service. To do so see the following article: The wizard will not allow you to continue without entering a DMZ address.
You will not be using the DMZ in this configuration so simply pick a private IP outside of any subnet you plan to use, and select a subnet mask of 255.255.255.0, if presented with a DMZ related error you can ignore. DHCP Server: We will deal with DHCP later along with the inside interface IP. Leave the current defaults “Enable DHCP” and the IP range for now. Address Translation (NAT/PAT): You will want to use PAT, so accept the defaults.
Administrative Access: This determines from which IP’s or subnets you can access the ASA 5505 to manage it, and using which protocols. The current default is using the ASDM from the 192.168.1.0 subnet. If you plan to change the IP of the router to a different subnet you need to add it now, before making changes to the inside interface’s IP.
Assuming you later plan to use 192.168.123.0/24 (/24 = subnet mask 255.255.255.0) for your local network, I recommend adding that subnet to the inside interfaces, using two rules, one for HTTPS/ADSM and the other for Telnet, by clicking the “edit” button”. Leave the “Enable HTTP server for HTTPS/ASDM access to this ASA” checked near the bottom.
Startup Wizard Summary: This page displays a summary of your choices. Review and click finish. Disable DHCP: Assuming you are running SBS 2008/2011 Standard and not SBS 20011 Essentials, you will need to turn off DHCP on the inside interface of the Cisco as the SBS server should most definitely be the DHCP server. If not convinced see: If running SBS Essentials the default is to have the router as the DHCP server, though it does not have to be.
To disable DHCP, log back into the ASDM if you are no longer connected, and navigate to; Configuration Device Management DHCP DHCP Server highlight the inside interface and click Edit” uncheck “Enable DHCP server”. Then click OK and Apply at the bottom. Change Inside interface (LAN) IP: As mentioned earlier, for the purposes of this article we will use 192.168.123.x (properly represented as 192.168.123.0/24) and choose 192.168.123.254 as the router inside interface IP but for your configuration match the current subnet of your SBS server. This will be the gateway IP for PC’s and servers on the SBS network. Navigate to: Configuration Device Setup Interfaces Highlight the inside interface and select Edit and change the IP to that of your choosing. Click OK, then check the box “ Enable traffic between two or more hosts connected to the same interface” at the bottom, and Apply.
Note: Should you choose to enable a VPN, using the Cisco or the SBS built-in VPN, the site from which a client connects, must use a different Network ID (Subnet) than that of the SBS LAN. As a result, nobody connecting from a remote site that uses 192.168.1.x locally can connect to resources on this network. Therefore it is always a best practice to avoid common subnets like; 192.168.0.x, 192.168.1.x, 192.168.2.x, 192.168.100.x 10.0.0.x, and 10.10.10.x. However if your SBS is already configured you would need to change the network addressing for the entire network. In the event you were to choose to do so make sure you use the wizard for changing the server IP located under SBS console networking Connectivity Connect to the Internet. You also have to change any DHCP scopes, reservations, exclusions and device with statically assigned IP’s such as printers.
Add a static route for the router’s default gateway: As mentioned before if you have with a static public IP assigned to the outside interface, you also have to create a static route to assign a default gateway to allow the router Internet access. To do so select Device Setup expand routing Static Routes and on the right click Add.
Select the outside interface, choose “any” for the Network from the drop down list and insert the gateway address assigned by the ISP, with a metric of 1. The remaining items should retain the default settings. Click OK and Apply. If you have not already done so, I would recommend saving all changes at this point by selecting from the menu File and then “Save running configuration to flash”, or at ant point simply press Ctrl+S to save. Configure port forwarding: SBS requires several ports be forwarded for various services. Below is an outline as to how to configure port forwarding for SMTP (port 25).
You will need to do this for each of the services in the following list that you plan to use:. SMTP port 25 Exchange. HTTPS / SSL port 443 Outlook web Access, Remote Web Workplace (Remote Web Access), and SharePoint.
SharePoint custom port 987 (SBS 2003 not required). RWW & Sharepoint 4125 (SBS 2003 only, not required for SBS 2008/2011).
PPTP port 1723 SBS VPN. The Cisco VPN is far more secure and moves authentication to the perimeter of the network. Far better to use it than the SBS VPN since it is included with the ASA 55050. RDP port 3389 (Definitely not recommended.
Much safer to use RWW/RWA) Add a NAT Rule: Login into the ASDM, remembering to use the new IP address of the router. Navigate to Firewall NAT Rules.
On the right under addresses there is an option to +Add, select this and then Network Object. Enter the name of the Object, in this case the SBS, enter the IP (in our example 192.168.123.10) and a subnet mask of 255.255.255.255. (Adding a network object is not completely necessary but makes reviewing configurations at a later date easier to understand as items are referenced by name rather than IP) Next in the same Window, under “Configuration Firewall NAT Rules” in the tile bar, click +Add and select Add Static NAT Rule. In the resulting window set the “Original” Interface to inside and next to source click the drop down list button. Select your new object (SBS-Server in this example). Set “Translated” Interface to outside, and check the box to “use interface IP address”.
Select Enable Port Address Translation (PAT), TCP, and enter either the port number, or in the case of most services you can enter the service name, if it is known to the Cisco router. A drop down list of known service will appear when you start to type the service name if one exists. If using non-standard services, enter the port number using the format tcp/987. The Original and Translated ports in this case should be the same. Click OK and this will add the rule to the list of static rules. Add an Access Rule: Next, again in the firewall section, Navigate to Access Rules Add Add Access Rule. Change the Interface to Outside, the Source will be “any”, Destination the outside interface, Service can again be selected from the drop down list, and add a description if you like.
Leave the “More Options” section set to defaults. Click OK and Apply. Repeat the above steps for all services you will be using, probably HTTPS/443 and SharePoint/987, and don’t for get to save ( Ctrl+S) when complete. This should complete the SBS requirements.
Additional Features you may wish to enable:. To enable pinging of internet IP’s from the LAN for testing, navigate to: Configuration Firewall Service Policy Rules highlight the policy under Global Policy and click edit Rule Actions check the box for ICMP click OK and Apply. To allow Tracert to internet IP’s, add the ICMP rule above, then while still under the Firewall configuration switch to the Access Rules item click Add Add Access Rule then set the interface outside, action is Permit, and Source/Destination is any. Under Service, enter icmp, it should auto-fill or you can use the drop down list line and click OK. Click OK again in the Add Access Rule dialog and Apply the results to finish the process.
With SBS 2008 if you wanted a Terminal Server to be listed with the computers to which a user could select on the RWW (Remote Web Workplace) page, you had to add a registry entry. With SBS 2011 adding the Terminal server (now called RDS or Remote Desktop Services Server) to the new RWA (Remote Web Access) page is pretty much the same only the key in which you create the entry doesn’t exist, so it is now a two step process. Note: This will not work on Server 2012 Essentials, and because it and SBS 2011 Essentials communicate with the same “connector”, I suspect it will not work on it either.
The change is intended for SBS 2011 Standard, or edit the existing key on SBS 2008 Standard or Premium. Update: Should you be looking for information regarding adding a 2012 RDS Server (Remote Desktop Server / Terminal Server) to an SBS 2008/2011 domain, please see the following more recent post: The normal warnings apply: making changes to the registry can negatively impact your server or even make it unusable. Before making changes to the registry, back it up and if not familiar with making registry changes it might be best not to proceed. Open the registry editor, as a domain admin, and locate the following key: HKLM SOFTWARE Microsoft SmallBusinessServer. Add a new key named RemoteUserPortal. Within that key create a new Multi-String Value entry named TsServerNames Then edit the new entry and insert as a value, the exact name of your Terminal (RDS) server. If you have multiple RDS servers add them each in a separate line of the value/data area.
Are you having Terminal Server (Remote Desktop Services) performance issues when logging on, redirecting printers, or the print spooler hanging? Eric Guo has a recent post outlining these performance issues can be due to; “hundreds or thousands of Inactive TS Ports”.”in certain scenarios on 2003 Terminal Servers and 2008/2008 R2 RDS Servers.” The first server I checked had hundreds. He has provided a tool “InactiveTSPortList” on CodePlex that will allow you to list and/or delete the inactive ports (requires Live ID sign in): Direct link to Codeplex.
Here’s a step by step guide on how to run multiple concurrent RDP sessions. My Test system configuration: Laptop running Windows 7 Enterprise (Windows Pro is recommended) - Main System Other Devices (clients): Iphone 3 Ipad Galaxy Tab 3 Required Software Patch: 2X Client for Desktops, Mobile Devices - Patch/crack Required to enable-concurrent-multiple-RDP-sessions: Windows 7 patch: Windows 8/8.1 Patch: Samarth Parikh's Blog on technology about his technical findings, quick guides, how tos, programmed codes, reviews about various gadgets & software. A: Select Allow Remote Assistance connections to this computer check box B. Select Allow connections from computers running any version of Remote Desktop to allow people using any version of Remote Desktop or RemoteApp to connect to your computer. This is a good choice if you don’t know the version of Remote Desktop Connection that other people are using, but it is less secure than the third option. Or Select Allow connections only from computers running Remote Desktop with Network Level Authentication to allow people with computers running versions of Remote Desktop or RemoteApp with Network Level Authentication to connect to your computer.
This is the most secure choice if you know that the people who will connect to your computer are running Windows 7 on their computers. (In Windows 7, Remote Desktop uses Network Level Authentication.) C.
Add Use Account for each RDP device.(in My example i have added Test 1 and Test 2. Test 1 user account (standard user) will connect using Iphone Test 2 user account (standard) will connect using IPAD Morshed user account (Admin) will be configured on Galaxy Tab. Step 2: Install Patch Required to enable-concurrent-multiple-RDP-sessions: My system is Windows 7, so i’m going to configure Universal Termsrv.dll Patch for Windows 7.
Choose the corresponding patcher based on your Windows 7: For 32bit(x86): U niversalTermsrvPatch-x86.exe For 64bit(amd64): UniversalTermsrvPatch-x64.exe Require administrator rights. Right-click the exe file, select Run as Administrator. Well maybe I’m the first to pipe in as a guy using this patch for less legally-questionable purposes (only Windows Server is licensed to allow more than one user on the PC at once - and licensing is super-critical for business purposes!) We’ve got a gaming PC in the living room connected to the TV, which is the most powerful PC in the house, connected to the home net via gigabit LAN. This would let me connect it to the stereo and play music without having to keep the TV on to manage it.
And the roommate can play games while I use the background idle time for other CPU-intensive tasks my laptop isn’t great for. I SO NEED THIS. Also figure it’s worth commending the site authors - the registration process here is insanely easy with very well-done Google integration, and this reply box is just awesome in every possible way. Update: Got the patch done on our PC - running 8.1 x64 fully updated. I didn’t feel safe using the pre-patched file, so I did it my own way with the help of the linked guide. Looking for the original bytes to patch, though, my version - updated on 4/2014 by Windows Update - didn’t have the full sequence of bytes. The pattern “0F 84 1B 70 00 00” at the end of the segment was different.
But knowing how assembly code works, I patched over the different bytes with “90” anyway (as the instructions indicated), and the patch worked great. In Windows 8, just like 7, Vista, and XP before it, SFC wants to protect the file.
I had to take ownership of termsrv.dll through the file properties, then give Administrators “full control” (only read is given by default). Then, I ran an rundll32 to sfcos.dll to disable SFC until reboot (I don’t want to totally disable SFC for this!), using “rundll32 sfcfiles.dll SfcTerminateWatcherThread” which gave no errors, then renamed the old file to termsrv.dll.bak, and copied my patched termsrv.dll into System32.
Termsrv.dll Crack Key
Rebooted, and I was able to log in from the laptop without logging off the user on the TV. So, basically:.
Termsrv.dll Crack Download
copy termsrv.dll to desktop. use hex editor to locate “8B 81 38 06 00 00 39 81 3C 06”. replace that, and the following bytes, with “B8 00 01 00 00 89 81 38 06 00 00 90 90 90 90 90 90 90” (do not expand the file). take ownership of termsrv.dll through Properties, and give Admins full control.
launch “rundll32 sfcos.dll SfcTerminateWatcherThread”. rename termsrv.dll to termsrv.dll.bak. copy patched termsrv.dll from desktop to System32.
Termsrv.dll Crack Windows
reboot And done!