At his point I’m going to assume you know that there are Standard Exchange CALs/SALs, and Enterprise Exchange CALs/SALs. And you know the difference! If you’re unsuresee my comments here.
With older versions of Exchange 2010/2007 etc. You could get this information from the GUI. Now you need to use some PowerShell.
Solution
The two commands you want to use are;
Find Out How Many Exchange Standard CALs / SALs Are Required
RemoteApp is a solution for delivering applications to your users from a Remote Desktop Services Server.
Why would you want to do this? Imagine you only had one copy of office to update in your entire organisation when a new service pack or security update is released., or Adobe bring out a new version of Dreamweaver that’s on all your machines – you simply update the master copy on the RDS server, or redeploy new RemoteApps.
In the following example I’ll configure the server, and create a RemoteApp application (Word 2010) and finally, deploy it to my domain clients.
Client requirements: Windows XP (SP2), Windows Vista, Windows 7, Windows Server 2003 SP2, Windows Server 2008, and Windows Server 2008 R2.
1. On a 2008 R2 Server (That’s a domain member), Start > Run > CompMgmtLauncher.exe {enter} > Roles > Add Roles > Remote Desktop Services > Add the following “Role Services” > Remote Desktop Session Host > Remote Desktop Web Access > (If you do not have a RDS Licensing services Licencing server add that also).
2. Select “Network Level Authentication” >Select your licensing mode > Add in the user(s) and/or group(s) you want to grant access to > Set your client experience options > Set the scope for the licensing server (per forest or per domain) > When complete let the server reboot.
3. If you do not already have a RDS Licensing server then activate the Licensing Server and follow the instructions. (Start > Administrative Tools > Remote Desktop Services > Remote Desktop Licensing Manager).
4. Then Start > Administrative Tools > Remote Desktop Services > Remote Desktop Session Host Configuration > Locate Licensing > And click the “Not Specified” > Then add in the licencing server you just activated.
5. Install and configure the applications you want to deploy. Then Start > Administrative Tools > Remote Desktop Services > RemoteApp Manager > Add RemoteApp Programs > Install and configure the desired application.
6. Add the computers that need access to RemoteApp(s) to the LOCAL group on the RDS server called “TS Web Access Computers”.
8. In the RemoteApp Manager select “Create Windows Installer Package” follow the instructions and put the resulting .msi file in a network share that your domain clients can access.
9. Send out the .msi file generated to your clients by group policy.
10. By default your deployed RemoteApps will be listed on the clients start menu under “Remote Programs”.
Related Articles, References, Credits, or External Links
Originally we had TS Web in 2003, and while I had a little play with it, it basically just gave you RDP over web, which would have been good if it ran over HTTP or HTTPS, but it didn’t. Also, as anyone who has ever done a complex Google search for “/tsweb” will testify, left a nice big security hole in to your servers.
With the release of Server 2008 we got TSWeb 2008, this was a whole different beast, and the web portal was very similar in operation to Citrix Web Presentation Server.
With Server 2008 R2, Terminal Services became Remote Desktop Services, so if you only have a couple of clients (i.e. don’t need an application farm etc,) then this might be just what you need, and buying licences for Remote Desktop Services is a LOT cheaper than buying the same licences plus Citrix licences that are about three times the price per seat.
I originally wrote this for TSWeb 2008, and updated it for Remote Desktop Services 2008 R2, I’ll leave the older information at the bottom for anyone who is still running 2008 R1.
Solution
Setup Remote Desktop Services Web Access on Server 2008 R2
1. In this example I’ve got a fresh server which is a domain member, and I’m going to put the Licensing server and the same box. From server manager (ServerManager.msc) >Roles > Add Roles > Next > Remote Desktop Services > Next > Next.
2. Everything is going on one server, you may want to split roles up in a larger production environment, but here we are adding Remote Desktop Session Host, Remote Desktop Licensing, Remote Desktop Gateway > Remote Desktop Web Access > Next > Next.
Note: When selecting role services, you will be prompted to “add required role services”, please do so.
3. I’m choosing the least secure method (choose this if you have older client running older versions of the RDP client) > Next > Either select a Licensing model (per user or per device, or select configure later) > Next.
Note: The licensing model chosen MUST match the CALS that will be in the licensing server. (If you are unsure configure it later, then you will have 120 days grace period to sort it out).
4. Add in which user groups to want to allow access to the host server > Next.
5. Decide which options you want to allow, to enrich your end user experience > Next > I dont need a scope as all my RD Servers will be 2008 R2, it you have TS servers as well you will need to configure a scope > Next.
6. If you already have a certificate you can select it here, I’m going to manually import the certificate into IIS at the end of the procedure > Select “Now” to configure the access policies > Next.
7. Add in which user groups you want to allow through the Remote Desktop Gateway > Next.
8. At the RDCAP screen, I’m just going to use passwords > Next > Then at the RDRAP screen, I’m going to allow connections TO ANY computer > Next > Next > let it install the Network Policy Server component > Next.
9. Install > Then go and have a coffee.
10. When completed, select yes to reboot which it will do (twice).
11. After you log back into Windows the installation will complete > Close
Import and Enable a Digital Certificate in IIS7
12. Start > Administrative tools > Internet Information Services Manager > Select the {server-name} > Server certificates > From here you can either create a certificate request, or complete a request, and import a certificate.
13. Here is my certificate with the “friendly name” WebServer.
14. To enable my certificate right click the “Default Web Site” (Assuming that’s where you have RDWeb installed) > Edit Bindings.
15. Select HTTPS > Edit > And select your SSL certificate > OK.
16. Restart the website (or run “iisreset /noforce” from command line).
18. Anything that needs configuring will have a yellow warning triangle, or a red cross over it. First you will see it’s complaining that there are no computers in the “TS Web Access Computer ” group.
19. That’s just a LOCAL group on the server itself, launch ServerManager >Configuration > Local Users and Groups > Groups > Locate the group.
20. Add in your groups as required > Apply >OK.
21. Back in the RemoteApp Manger > Check the RD Session Host Server >Settings (on the menu on the right) > Make sure the PUBLIC name (which will be the CN on your digital certificate) is displayed NOT the LOCAL FQDN of the server. You can also tick the option (shown with the arrow) to display the RDP shortcut to your users on the web portal. > Apply > OK.
22. To do the next step, you need to have the applications you want to give to your users, actually installed on the server. > Either right click at the bottom, or select “Add RemoteApp Programs”.
23. Follow the wizard, and select the programs as required.
24. Click refresh > Make sure there’s no more red/yellow warnings > Close RemoteApp Manager.
25. To test it, connect to your server on https://{servername}/RDWeb and log in.
26. You applications should be shown, give them a test, here I’ll launch Outlook.
27. I already have Outlook configured on the Remote Desktop Server so mine just opens (your users will need to setup Outlook, if they don’t have a profile on the RD server already).
Setup Terminal Services Web Access on Server 2008 R1
1. Start > Server Manager (or Start > run > CompMgmtLauncher.exe (Enter) > Add Roles..
3. Select the application you require or browse to its Executable > Next. >
4. Finish.
Connecting from a client
1. On a Client PC open internet explorer > Navigate to http://{serverIP or name}/ts > Note: If you do not have ActiveX enabled and the latest RDP client you may see this error.
2. There’s your applications > simply select one.
3. Enter your login credentials.
4. Wait for the application to deploy.
5. And there you go 🙂
Related Articles, References, Credits, or External Links
Been a while since I’ve seen this one, and strangely I didn’t document it. so when I was asked this morning I searched here on PeteNetLive, and In my personal database of solutions but the cupboard was bare.
Solution
1. Before you do anything make sure your SBS has plenty of space on the hard drive, simply running out of room on the system drive can cause SBS to lose its licences, make sure this is not your problem.
2. If you have plenty of room, then click Start > Run > services.msc {enter}. Locate the Licence Logging service > Right Click > Stop.
3. Locate the licstr.cpa file (it’s in C:windowssystem32 by default) > Rename it to licstr.OLD.
4. Locate the autolicstr.cpa (Should be in the same folder) and COPY it to your desktop to create a backup, Then rename the original to licstr.cpa
5. Back in the services console restart the “Licence Logging Service”.
6. Your licences should now be back in place.
7. Finally, you will notice there’s an option in the Licensing console to back up your licences, now would be a good time, to avoid having to do this again.
Related Articles, References, Credits, or External Links
To complete a migration from Exchange 2010 (or 2007) to Exchange 2016/2013, you need to introduce Exchange 2016 into your existing Exchange environment, then migrate your content onto the new server(s), and finally remove Exchange 2010.
Solution
Assumptions:
In this example I’ve got an existing Exchange 2010 environment running on Windows Server 2008 R2. I’m putting in Exchange 2016 onto a new server running Server 2012. Post install the NEW server will hold client access, and mailbox roles.
Exchange 2013/2016 Role Placement
Unlike with previous versions of Exchange, the 2016/2013 approach is NOT to split up roles to different servers, it’s considered good practice to deploy all roles on all Exchange servers.
Exchange 2013/2016 Licensing
Unless you have Microsoft “Software Assurance” you cannot simply upgrade to Exchange 2016 for free. You will need to buy the Exchange 2016 Base product. You may wish to look at an “Open Value Agreement”, which lets you pay the cost over a three year term.
The Exchange 2016 (on-premises) software itself comes in two flavours, Standard and Enterprise.
Standard: For small Exchange deployments (1-5 Mailbox Databases) and for non mailbox role servers in larger Exchange deployments.
Enterprise: For large Exchange deployments (1-50 Mailbox Databases).
Exchange 2013/2016 Client Access Licenses
As before there are two types of CAL for Exchange 2016 access. These are also ‘confusingly’ called Standard and Enterprise.
Note: An Enterprise CAL is NOT just for Exchange Enterprise 2016 and a Standard CAL is NOT just for Exchange Standard, this is a common mistake. Though you can mix and match, i.e. a standard CAL is required for all mailbox users or devices, adding an Enterprise CAL is only required for those existing users or devices requiring additional functionality.
Standard CAL: Required for all users (or devices) that require access to an Exchange mailbox. For most people these will be the CALS you need to purchase.
Enterprise CAL: Is an additional license that’s added to the Standard license, this enables the user to use archiving/journaling and unified messaging (Requires Outlook 2013). It also gives access to more advanced ActiveSync management policies and custom retention policies.
Exchange 2016/2013 Migration Step 1 “Planning / Pre Site Visit”
1. Media and Licenses: Before you start you will need to have the Exchange 2016 or 2013 CU2 (CU1 = Minimum) version of the install media (.iso or DVD). DO NOT attempt to perform the migration with a version of Exchange 2013 media that IS NOT at least CU1. Warning, this will be a DVD image (over 3.5 GB), you may wish to get this downloaded from a site with a decent Internet connection!
2. Make sure any third party Exchange software you are currently running is also supported on Exchange 2016, e.g. Anti Virus, Backup Solutions, Archiving, Mail Management, Mobile Device Software, etc, check with the software vendor.
3. DO NOT CONSIDER migrating anything until you know you have a good backup of your current Exchange environment. If you are lucky enough to have VMware ESX, Hyper-V or another virtualisation platform, consider doing a P2V conversion on your Exchange 2010 server then simply turning the 2010 Server off, then if it all goes to hell in a hand cart simply turn the original server back on again.
4. Outlook Client Access: Be aware your clients need to be using the following versions of Outlook BEFORE you migrate them.
I would suggest you run through the Microsoft Exchange Server Deployment Assistant, as a “Belt and braces” approach to the migration”
1. Before you do anything, it’s time for a common sense check, make sure your existing Exchange 2010 Organisation is happy and running cleanly, and has good communication with both the domain and your DNS. Get in the event logs and make sure it’s a happy server.
Time spent on reconnaissance is seldom wasted!
2. Run a full Windows update on your existing Exchange server(s), this will install any Exchange roll-ups that are outstanding.
3. If you are planning to utilise DAG, then you should install the following hot-fix on your Exchange 2010 servers before deploying SP3.
4. For coexistence of Exchange 2010 and Exchange 2016/2013, Your Exchange 2010 Servers must have Service pack 3 installed. If you are upgrading from service pack 1 you may see the following error.
1. The server that will run Exchange 2016, will need to be a domain member*, and I would run all the current updates before you start.
Once that is complete there are a number of server roles that will need adding. (Note: in Exchange 2013 these roles are the SAME for both CAS and Mailbox Servers, in 2016 there is only mailbox and edge servers anyway).
*Note: As with previous versions of Exchange it is recommended that you DO NOT run Exchange 2016 on a domain controller.
To add the Exchange 2013/2016 Server roles via PowerShell
Note: Here on my ‘Test Network’ the server in question is also a domain controller. In your production environment this will probably NOT be the case. If so, you will need to install the Remote Server Administration Tools for Active Directory.
6. I tend to disable feedback, but the choice is yours > Next.
7. Select the server roles that you wish to install.
8. Select the folder that you wish to install the Exchange program into.
Note: Remember if deploying multiple Exchange 2013/2016 servers, it’s considered good practice to keep the folder paths contiguous across all the servers.
9. If you plan to deploy third party malware protection (post Install), then you might wish to disable this, but in most cases you will want it enabled > Next.
Note: This is built on technology that was called ‘Forefront’ in previous versions of Exchange.
10. Pre deployment readiness checks will be carried out > when complete > Next.
11. Setup will take quite some time.
12. When complete, tick the box to launch the admin console > Finish.
13. After a few seconds the Exchange Admin Center will open.
Note: If you log in and get a blank screen, ensure your users has ‘inheritable permissions’ enabled, (on the security tab of their user object in AD)
14. At this point I would move the new Exchange Database from its default location to its own volume/folder, (again keep this path contiguous across all the new servers). The following PowerShell command will do this for you;
STOP! Before you proceed you need to think about OWA access. For internal access this will not be a problem BUT if you have users that access OWA externally (e.g. via https://mail.yourpublicdomain.com/owa) Then you will have to DO SOME PLANNING. Unless you have two free public IP addresses, your router/firewall can only point to one CAS server at a time.
STOP AGAIN! OK I’ve had more than one email about this so, here’s a warning. Moving Mailboxes creates logs, the more you move, the more logs it creates. The only way to clear these logs properly is to do an Exchange Aware/VSS Level backup. If you just start moving mailboxes without keeping an eye on this you can fill up a volume with logs, and if you are daft enough to have this on our system volume you can take the server down, you have been warned! OrSee the following Article
1. First make sure that the new server can see the existing Exchange infrastructure. From within the Exchange Admin Center > Servers. You should see both your Exchange 2010 Servers and the new Exchange 2016 Server.
Note: You can see the same with the following PowerShell command;
[box]Get-ExchangeServer | select Name, ServerRole, AdminDisplayVersion | ft –auto[/box]
2. Test move one mailbox from Exchange 2010 to 2016, Recipients > Mailboxes > Locate our Test User > Move Mailbox.
3. Give the test migration a name, and browse to the new datastore (Note: If the move fails you can increase both the BadItem limit and the LargeItem limit here as well) > Next.
4. New.
5. You will be asked if you want to the ‘Migration Dashboard’.
6. Here you can watch progress (remember to keep hitting ‘refresh’).
7. If you prefer to use PowerShell you can migrate all mailboxes from one database to another with the following command;
Depending on the amount of mailboxes this can take a while!
8. Then test mail flow to/from this mailbox to internal recipients in the Exchange 2010 infrastructure, and then test mail flow to/from an external mailbox.
Note: At this point you might struggle to connect to the Exchange 2016 Admin Center as ‘Administrator’, because that user’s mailbox is still on the Exchange 2010 Server. If that happens to you and you are ‘Locked Out‘ of the Exchange Admin Center, simply add the user you migrated already, to the Exchange Organization Management group, and log in as that user to https://{Exchange-2016-Server-Name}/ecp
9. You can now migrate the remainder of your mailboxes.
Note: Depending on mailbox size this can take a VERY LONG time, I would suggest staging this migration gradually. To view progress;
Exchange 2013/2016 Migration Step 6 “Change Mail flow”
At this point you need to change the SMTP feed from the old Exchange 2010 box to the new Exchange 2016 Server, how you do this depends on your network setup, some examples of how you might do this are,
i. Change the SMTP (TCP Port 25) Port redirect on your router/firewall.
ii. Swap IP addresses from the old to the new server.
iii. Change the translation from public to private IP address to point to the new IP.
Note: If you have any mail scanning servers, anti spam hardware devices etc, then they will also need changing to point to the new server.
1. You will need to add the new server to your Exchange ‘Send Connector’ and remove the Exchange 2010 Server. (Note: I’m assuming you only have one send connector, if you have more than one i.e. for particular domains, or for secure TLS mail you will need to do these as well). From Exchange Admin Center > Mail flow > Send connectors > Select the send connector > Edit > Scoping > Add the 2016 server > Remove the 2010 server > Save.
2. You will not need to create receive connectors on the Exchange 2016 Server, if you navigate to mail flow > receive connectors > Change the drop down to point to the Exchange 2013 Server. You will see there is a ‘Default Frontend’ Connector already configured for Exchange 2016.
3. At this point, it would be sensible to once again check mail flow, to and from an external mail account.
Related Articles, References, Credits, or External Links
Thanks to Simcha Kope for the feedback (Adding RSAT-ADDS)
Thanks to Austin Weber for spotting my PowerShell typo.
Thanks to Tony Blunt for the log file PowerShell syntax omission.
