Archive for the ‘TS/RDS’ Category

Shutdown Event Tracker

Recently after a dirty shutdown one server kept displaying the familiar “Why did the computer shutdown unexpectedly” for all users, at every logon.

Usually a reboot resolves this, but did not. I have heard of this happening over the years due to specific updates, but no updates had been applied recently. Ultimately it required locating the registry key which contains the flags to initiate the popup; \HKLM\Software\Microsoft\Windows\CurrentVersion\Reliability and deleting any subkeys referencing the last event, such as “DirtyShutdown”. These keys get recreated after the next event. Changing values from 1 to 0 will stop the popup, but this disables it all together. Not a good idea. Of course; make sure you backup the registry before doing so and do not make changes to the registry if you are not familiar with doing so.

Advertisement

Install Office on Remote Desktop Server

You cannot install a standard version of Office on an RDS server.  Prior to Office 365 you had to buy Enterprise licenses for each user which are quite expensive.  I understand Enterprise licenses are still available and I assume they will still work but you may already have a suitable Office 365 subscription, or you can upgrade to one that will.   Your Microsoft 365 license must include Office Pro Plus, a Business Standard license will not work.  There is an Office Pro Plus license or an E3 or higher license includes Office Pro Plus.  With Office/Microsoft 365 you can use your current licenses but have to download a special installation version and jump through a few hoops.  This method is supported by Microsoft.

(Oct 2020 update: Microsoft has changed the naming of it’s Office 365 subscriptions to new Microsoft 365 names. I believe the minimum license level now is Microsoft 365 Business Premium but be sure to confirm with your vendor. The following is a Sept 2020 article referencing the install with the new licenses https://docs.microsoft.com/en-us/deployoffice/deploy-microsoft-365-apps-remote-desktop-services#:~:text=If%20you%20use%20Remote%20Desktop%20Services%20%28RDS%29%20to,installation.%20The%20following%20are%20two%20common%20RDS%20scenarios%3A )

Note: when installing apps on terminal servers in the past you had to put the server in “Install mode” by running from an elevated command prompt 

  •    Change User /Install
  • and to exit Install mode run
  •    Change User /Execute

Though this is still recommended, I tried it without doing so and it worked, but make sure you are an administrator of the machine (local or domain) and all other users are logged out. I recommend a clean reboot before starting.

Create a shared folder such as \\RDS\O365 pointing to C:\Temp\O365  

Download the Office deployment tool from the link below and extract to your shared folder  \\RDS\O365

https://www.microsoft.com/en-us/download/details.aspx?id=36778

Create an .xml configuration file for the download and save to the same folder. I named DownloadConfig.xml 

<Configuration> 
  <Add SourcePath="\\RDS\O365" OfficeClientEdition="64"> 
   <Product ID="O365ProPlusRetail" > 
     <Language ID="en-us" />      
   </Product> 
   </Add> 
</Configuration>

Download the custom version of Office.  To do so open an elevated command prompt, change to the directory containing the .xml file  C:\Temp\O365\MayBeSubfolder and run the following command.

setup.exe /download DownloadConfig.xml

This may seem like it hangs, but wait.  I believe it took about 15 minutes with my connection.

Create another .xml configuration file for installation and save again to the same folder. I named InstallConfig.xml

<Configuration>
  <Add SourcePath="\\RDS\O365"
       OfficeClientEdition="64" 
       Channel="Monthly">
    <Product ID="O365ProPlusRetail">
      <Language ID="en-us" />
    </Product>
  </Add>
  <Display Level="None" AcceptEULA="True" /> 
  <Property Name="SharedComputerLicensing" Value="1" />
  <Logging Level="Standard" Path="C:\Temp" />
</Configuration> 

Deploy Office using:  \\RDS\O365\setup.exe /configure  \\RDS\O365\InstallConfig.xml

Note: you must use the full path

Again it may appear to hang, but be patient

If you ran Change User /Install before starting, run Change User /Execute

Microsoft has more detailed information and options to customize the xml files at:

https://docs.microsoft.com/en-us/deployoffice/deploy-microsoft-365-apps-remote-desktop-services

https://docs.microsoft.com/en-us/deployoffice/office2019/deploy

Remote Access

Many years ago I wrote numerous blog articles relating to VPNs, and primarily PPTP VPNs. Hits on those blog pages are up 300% since the Coronavirus outbreak due to people looking for ways to work from home. I wanted to warn PPTP is an old solution and is considered to be “broken” and very insecure. Please consider other options.

Rather than creating new articles explaining how to configure various remote access methods I thought I would provide some suggestions and links as it has all been written before by very talented IT folk.

Firstly VPNs. I would always recommend using a VPN appliance/router over the server itself. It is more secure, authenticates at the network perimeter not the server itself, and allows more control. Cisco, Sonicwall, Juniper, Watchguard, and others provide very good solutions . However one concern with any VPN solution is the fact that though it is a secure tunnel, it also allows any and all traffic between an unmanaged remote client computer and the corporate network. Viruses can travers the VPN tunnel, should the client PC be hacked the hacker has direct access to the corporate network, and the remote user can easily copy/steal corporate data that they maybe should not. In addition VPNs occasionally just do not work due to network addressing, slow ISP service, or blocked protocols by ISPs.

If you do want to set up a VPN on a windows server, I would recommend SSTP.  Thomas Maurer has a great configuration guide:https://www.thomasmaurer.ch/2016/10/how-to-install-vpn-on-windows-server-2016/

Perhaps a better option than a VPN is a terminal server, now called a remote desktop server (RD Server). I have never seen the RDP protocol blocked, performance is usually better than a VPN, and all data stays on the corporate network. If set up correctly it uses the Remote Desktop Gateway service and SSL which is very secure. You can, if you like, also use this within your VPN tunnel and if using a business class VPN solution restrict traffic to RDP.

Another alternative if you don’t want to set up an RD Server is to configure the RD Gateway service on your server and allow users to connect securely to their own desktops PCs with the same level of performance. This was a built in feature of SBS and Server Essentials 2016 and earlier.  Mariette Knap has a excellent article on configuring the RD Gateway service, specifically on Server 2019 Std:https://www.server-essentials.com/support/setup-rds-gateway-as-a-replacement-for-access-anywhere-from-the-essentials-experience-role

Regardless of what method you use, as soon as you allow any remote access, make sure you configure Group Policy to enforce strong passwords and to lock accounts after ‘X’ wrong password guesses.  (I use 5, and lock out for 30 minutes). You can set this on the server for domain wide deployment or on an individual PC using GPedit.msc. For both it is located under Computer Configuration |Windows Settings | Security Settings | Account Policies .

The other alternative of course is to use cloud based services such as Microsoft’s Office 365 which you can from any where, at any time.  If dong so, make sure you enable multi-factor authentication for security.

I hope this is of some help and please stay safe n these uncertain times.

 

 

 

An Authentication error has occurred

It seems recently many users are receiving an error logging into Remote Desktop Servers (Terminal Servers) from off-site. The error reads:

KB4103725

An authentication error has occurred.
The function request is not supported.
Remote computer <ServerName>
This could be due to CredSSP encryption oracle remediation.
For more information, see https://go.microsoft.com/fwlink/?linkid=866660

This is a result of a March 13th update. The previous error message was shorter, but an Apr 17 update elaborated the error message to read as above.

The link explains how to resolve using group policy but the simple fix, as of May 8th, is to apply the KM4103725 monthly rollup update. This will require a reboot on most servers, but should resolve the problem once complete.

 

Multiple RDP Sessions on a PC –legal or not

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 Experts-Exchange 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 <http://www.petri.co.il/multiple-remote-desktop-sessions-on-windows-xp-sp3.htm>

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 <http://www.nextofwindows.com/how-many-concurrent-connections-allowed-to-access-a-windows-7-computer/

I think you find it is a license violation, as win 7 is single user at time OS.
As with all version of windows you need a license for all current users.
If you “hack it” you have violated the TOS and have voided the windows license.  From <http://social.technet.microsoft.com/Forums/windows/en-US/41e9e500-714a-443b-bff2-55f0d500d3d1/concurrent-sessions-remote-desktop-in-windows-7>

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 EULAFrom <http://www.optimusbi.com/2012/12/05/enable-concurrent-rdp-connections-windows/>

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.   From <http://arstechnica.com/civis/viewtopic.php?f=15&t=1190558

Add 2012 RDS server to SBS 2008/2011

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 Remote FX feature, RDP on steroids, which provides substantially better performance when remotely running graphic intensive applications, but there are other Remote FX bonus elements as well, in addition to other 2012 RDS features.  Remote FX was included with Server 2008 R2, but the pre 2012 hardware requirements 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

image

  • 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”

image

  • Next, as mentioned earlier, choose “Role Based or feature-based installation”

image

  • Select the local server

image

  • Select the “Remote Desktop Service” role and click next

image

  • Do not select anything in the Features window, click next

image

  • 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

image

  • Click Add Features.

image

  • Select restart the server automatically, and choose install.

image

  • 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.

image

  • 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.

image

  • 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: https://blog.lan-tech.ca/2011/12/12/add-a-terminal-server-to-the-sbs-2011-rwa-page/   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: https://blog.lan-tech.ca/2012/05/17/sbs-2008-2011-adding-an-ssl-certificate/
  • 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.
  • image

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.
  • image
  • 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.
  • image
  • 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.

image

  • 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.

image

Your RDS server should now be fully functional.

Configure Cisco ASA for SBS 2008/2011 Network using CLI

I recently posted an article entitled “Configure Cisco ASA for SBS 2008/2011 Network using ASDM” 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).

Basic router configuration; router name, domain, outside/WAN static IP and subnet mask, and management access:

hostname Cisco-ASA5505
domain-name MyDomain.local
Interface vlan2
ip address  123.123.123.123 255.255.255.248
no http 192.168.123.0 255.255.255.0 inside
http 192.168.123.0 255.255.255.0 inside
no telnet 192.168.123.0 255.255.255.0 inside
telnet 192.168.123.0 255.255.255.0 inside
enable password MyPassword

Disable DHCP on the Inside/LAN interface and set inside/LAN IP:

no dhcpd enable inside
Interface vlan1
no ip address
ip address  192.168.123.254 255.255.255.0
same-security-traffic permit inter-interface

Set default gateway on Outside/WAN interface:

route outside 0.0.0.0 0.0.0.0 123.123.123.121 1

Configure port forwarding for port 25 (SMTP/Exchange), port 443 (Https/RWW/RWA/OWA/Sharepoint), and port 987 (Sharepoint):

name 192.168.123.10 SBS-Server
asdm location 192.168.123.10 255.255.255.255 inside

static (inside,outside)  tcp interface 25 192.168.123.10 25 netmask 255.255.255.255 tcp 0 0 udp 0
static (inside,outside)  tcp interface 443 192.168.123.10 443 netmask 255.255.255.255 tcp 0 0 udp 0
static (inside,outside)  tcp interface 987 192.168.123.10 987 netmask 255.255.255.255 tcp 0 0 udp 0

access-list outside_access_in remark Allow SMTP traffic
access-list outside_access_in extended permit tcp any interface outside eq smtp
access-list outside_access_in remark Allow SSL-OWA-RWA Traffic
access-list outside_access_in extended permit tcp any interface outside eq https
access-list outside_access_in remark Allow SharePoint traffic
access-list outside_access_in extended permit tcp any interface outside eq 987
access-group outside_access_in in interface outside

Allow pings from LAN to Internet:

policy-map global_policy
class inspection_default
inspect icmp

Allow Tracert (requires ping policy changes above):

access-list outside_access_in line 3 remark Allow Tracert
access-list outside_access_in line 4 extended permit icmp any any

Save:

write mem

Configure Cisco ASA for SBS 2008/2011 Network using ASDM

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: https://blog.lan-tech.ca/2012/01/25/configure-cisco-asa-for-sbs-20082011-network-using-cli/ ]

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 https://192.168.1.1 , 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.

image

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.

image

Interface Section: Leave all a defaults.

image

Switch Port Allocation:  Again the defaults are fine for this configuration.

image

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: Using DDNS Services with SBS 2008/2011

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.

image

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.

image

Address Translation (NAT/PAT):  You will want to use PAT, so accept the defaults.

image

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.

image

Startup Wizard Summary: This page displays a summary of your choices. Review and click finish.

image

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: Do I absolutely have to run DHCP on SBS 2008?  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.

image

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.

image

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.

image

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)

image

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.

image

Click OK and this will add the rule to the list of static rules.

image

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.

image

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.

Add a Terminal Server to the SBS 2011 RWA page

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: https://blog.lan-tech.ca/2013/04/11/add-2012-rds-server-to-sbs-20082011/

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

  1. Add a new key named RemoteUserPortal
  2. 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.

TS/RDS performance issues.

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):

http://social.microsoft.com/Forums/en-US/partnerwinserver7rcthreads/thread/c860f54b-2d16-495f-9e5f-d28d72d63302

Direct link to Codeplex:

http://inactivetsport.codeplex.com/

Tag Cloud