I am pleased to announce my Windows Phone 8 Blog app has been published. As of yet it is not compatible with Windows Phone 8.1 but should be by the time of “official” release. The app, which is free, can be downloaded from: http://www.windowsphone.com/en-us/store/app/lan-tech-blog/d0bd5f80-c223-48ae-a13e-a978913198b0
I have had a few questions regarding a message “Office 365 authentication did not succeed” suddenly appearing both in the daily reports and the Alert Viewer of Server Essentials. The alert viewer suggests changing the admin account (or refresh it) in the Office 365 tab of the Essentials Dashboard, however doing so fails with a message stating you are using the wrong account or password.
In most cases if you log into the Office 365 site using the domain’s admin e-mail account you will find the password has expired and you are asked to update it. Do so and return to the Dashboard entering the new password which should now allow it to validate and eliminate the error.
The past 8 or more years most of us have managed PC updates using WSUS (Windows Server Update Service) and Group policy. However, the structure of the modern office has changed to a large percentage of mobile employees who never ‘touch down’ at headquarters. If these devices do not connect to the domain they do not have updates applied.
A client who has not returned to the office in 18 months, and likely will not for the life of their laptop, recently asked how they could update their machine manually. Currently they were not able to do so as Windows Update showed “settings are managed by your system administrator”, in other words, by WSUS
It is quite simple to disable WSUS management in the registry, however remember if the device is reconnected to the domain, the WSUS policies will be reapplied. Therefore you may want to move the device to an OU not linked to the WSUS policy or remove the device in the policy under security filtering.
Disclaimer: Be aware making incorrect registry changes can have disastrous effects to the health of the device. Be sure to backup the registry before editing. To do so see the following Microsoft article; “How to back up and restore the registry in Windows” http://support.microsoft.com/kb/322756
- Open the registry editor, by entering Regedit in the Start / Run box, and browse to: HKLM\Software\Policies\Microsoft\Windows\
- Locate the WindowsUpdate Key and delete it
- Reboot the PC (may take 2 reboots)
- Now you can manually update and configure Windows updates to automatically check for and install updates directly from the Microsoft Update site
You may want to consider using a newer service such as Windows Intune to manage your computers, especially mobile devices. http://www.microsoft.com/en-us/server-cloud/products/windows-intune/
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 EULA. From <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
It seems the Java download site has been down for 24 hours. Many internet posts by folk receiving “This page can’t be displayed” after clicking the download button. The “See all Java downloads” page results in the same message.
A site test reveals it is down as well: http://downforeveryoneorjustme.com/javadl.sun.com
I did find the Oracle site worked without any problems: http://www.oracle.com/technetwork/java/javase/downloads/jre7-downloads-1880261.html
There are many articles regarding how to locate and regain space consumed by many SBS services and log files, including one of my own; “Missing SBS 2008/2011 Drive Space“. One of the most common issues is the WSUS admin logs located in C:\inetpub\logs\LogFiles\W3SVC_____ which can consume huge amounts of drive space. With SBS 2011 and SBS 2008 (2008 if updates are applied) this particular folder should be looked after by a scheduled task which clears out log files older than 100 days. In a few cases you may want to edit this and reduce it to a shorter period of time, as very nicely explained by Ronny Pot.
I was asked to look at an SBS server today which had ‘lost’ most of its system partition available space. It was not really lost as it was found in a C:\inetpub\logs\LogFiles\W3SVC_____ folder. However, this should have been looked after by the aforementioned scheduled task. Upon review of the task history it seems the task’s script has been failing for several months resulting in “Action start failed” and “Action failed to start” messages with an Error Value of 2147942402.
Note: the task is located under Administrative Tools | Task Scheduler | Task Scheduler Library | Microsoft | Windows | Windows Small Business Server 20xx Standard | WSUSLog Cleaner
In this case the time frame had been reduced to 30 days, but noticed when saving the changes, if not paying attention, the “arguments” for the script can get modified by Windows. The changes can be made under the Actions tab as per the image below:
However, in some but not all cases, when clicking OK to save you may get a popup as below:
Note the text. If you select yes it changes the Program/Script field to C:\Program, and the Argument field to Files\Windows Small Business Server\Bin\WSUSLogCleaner.vbs 30. The entire path needs to be in the Program/Scripts field and only 30 in the argument. It seems someone in a hurry clicked yes, as one would assume when approving changes, and did not double check after the fact. It seems the popup only occurs if there are no existing quotes around “C:\Program,Files\Windows Small Business Server\Bin\WSUSLogCleaner.vbs” in the Program/Scripts field.
In the past I wrote a couple of articles explaining how to connect to a business network using a Windows VPN prior to logon, so that domain authentication takes place and group policies and logon scripts are applied. See: Win 7 and earlier and Win 8
As pointed out in the articles, this only works for domain joined computers. It has been brought to my attention that some folks would like to automate the VPN connection process on non domain joined machines. .
Automate VPN connection – AFTER logon:
Basically you need a one line batch file and add it to the startup folder, but in detail:
- Open a text editor such as Notepad and enter the lines below, substituting the name of your VPN connection for Acme, and inserting your user name and password
rem Batch file to establish a VPN connection
rasdial acme username password
- Substituting * (an asterisk) for the password, will prompt for the password during the connection. This is more secure as the password is stored in clear text in the batch file.
- Save the file to a location such as the desktop, but when doing so save using a .bat extension and enclose the name in quotes such as; “VPN_Connect.bat”. Notepad will add a txt extension if you do not use the quotes.
- Saving to the desktop allows the user to double click on the file to establish the VPN connection.
- If you want to automate the connection add the batch file to the startup folder and it will run after logon to the PC has completed. The startup folder can be found in the following locations:
XP: Documents and Settings\All Users\Start Menu\ Programs\Startup
Win7: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp
For those following my blog in Atlantic Canada, you may be interested in an upcoming local event:
An Introduction to Microsoft Virtualization and the Private Cloud with System Center 2012 and Hyper-V
Spend an evening with Mitch Garvis, Virtual Technology Evangelist with Microsoft Canada, getting to know the Microsoft server virtualization story. Learn not only about Hyper-V, but also the management and Private Cloud scenarios that System Center 2012 SP1 brings to the table, Learn how to build your cloud, and also how Microsoft sets itself apart from (and ahead of) the competition in the Virtualization world!
This informal event will consist almost entirely of discussions and demos, with only a smattering of PowerPoint and fluff. The demos will be entirely unscripted, so you will get to ask what you want to see… and Mitch will do it!
The event is to be held Tuesday, June 11, 2013 from 5:30 PM to 9:00 PM, at the Nova Scotia Community College Institute of IT Campus, 5685 Leeds St., Halifax, NS
To register: http://www.eventbrite.com/event/6998359281
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.
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: http://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: http://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.
- 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.
- 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 was amused the other day to discover the two gophers that many of us remember from our childhood cartoons were named Mac ‘n Tosh. The cartoon was first created by animator Robert Clampett in 1947 for the short film “The Goofy Gophers“, thirty-seven years before the release of the first Macintosh computer.