In the last few
months, the crisis with COVID19 has put organizations in a panic to enable employees
to be able to work from home, to continue business productivity, keep employees
safe, and keep employees on the payroll. It’s good for business, and it’s good
for employees to avoid layoffs so everyone keeps their jobs.
This has put IT departments and IT professionals in a hectic position where they must roll out and deploy remote access technologies on the fly, often with little or no notice.
I’ve heard horror stories where organization leadership has made decisions without consulting IT which resulted in the inability to work, also where organizations didn’t involve their IT teams in strategizing and planning moving forward.
In this post I’m going to outline the most efficient way to rapidly deploy Remote Desktop Services (RDS) for employee remote access.
Remote Access Technologies
There’s a number of different remote access technologies and software packages available today. Some are designed to allow you to work fully remotely (providing a remote desktop to office resources), and some are designed to provide access to specific resources remotely (such as documents, files, etc).
The main technologies typically used for remote access include:
Miscellaneous 3rd party packages providing remote access to desktops
The main software packages that enable a remote workforce include:
Microsoft Office 365
Skype for Business
Numerous other applications and cloud suites
Every technology or application has it’s purpose and is deployed depending on the business requirements, however in this specific situation we need a solution that is easy and fast to deploy.
For most small to medium sized businesses, Remote Desktop Services would be the easiest solution to roll out on such short notice.
Remote Desktop Services (RDS)
Remote Desktop Services is a server/client technology that allows the client to connect to the server, and have access to a full Windows desktop that’s actually running on the server itself.
These sessions are encrypted, secure, and essentially brings the display to the connecting client, and brings back mouse and keyboard feedback.
With Remote Desktop Services, you’re maintaining one Windows Server that provides multiple concurrent sessions for multiple concurrent users. You can install software packages (database applications, Microsoft Office 365, and other line of business applications), and make them available to the connecting users.
Even users who are accessing large files have a beautiful experience since the data never leaves your IT environment, only the sessions display is transmitted.
This works great for home users who have slow internet connections, users who are travelling, or using their cell networks LTE connection to connect.
For administrators, it provides an easy way to manage a desktop experience for multiple users by maintain a single server. There are also many additional controls you can implement to limit access and optimize the experience.
When deploying RDS, you’ll need the following:
A dedicated Server or dedicated Virtual Machine running Microsoft Windows Server to be configured as a Remote Desktop Services server.
Remote Desktop Services CALs (Client Access Licenses – One CAL is required for each user or device)
A high speed internet connection (that can handle multiple RDS sessions)
A firewall to protect the RDS Server and preferably 2FA/MFA logins
A Static IP and DNS entries to make the server available to the internet and your users
You’ll want the RDS server to be dedicated strictly to Remote Desktop Services sessions. You will not want to run any other servers or services on this server or virtual machine.
You will need to purchase RDS CALs. A Remote Desktop Services Client access license, is required for every device or user you have connected to your RDS server. During your initial purchase of RDS CALs, you must choose between user count based licensing, or device count based licensing. If you need help with licensing Microsoft Remote Desktop Services, please feel free to reach out to me.
The connections between the server and client consist of an encrypted presentation of the display, as well as mouse/keyboard feedback, and other peripherals. For a single session it’s not much, which means your users don’t ultra fast internet connections. However, on the server side if you are running multiple sessions, the bandwidth requirements add up.
Configure Remote Desktop Services and Remote Desktop Web Access
Configure an SSL Certificate
Configure user session settings
Install user software on the RDS Server (Including Office 365, Line of Business applications, and others)
Configure ACLs (Access Control) to secure user access.
Move to production
Even with limited to no experience with Remote Desktop Services, an IT professional will be able to deploy the first server within hours. A focus must be paid to securing the environment, performance enhancements can be made later after deployment.
Your new RDS server while enabling a mobile workforce, also substantially increases your security footprint. Considerations must always be made and factored in when deploying internet available services.
Below is a video demo of what Duo Security Two Facter authentication looks like when logging in to an RDP session.
There’s a fair number of optimizations which can be made in an RDS environment. I’m going to cover a few of the most widely used below.
Please note, you should also configure the RDS Group Policy Objects (GPO) as well.
While most data should be stored on network shares, we often find that users will store data and files on their Desktop and My Documents.
If you have available and extra storage, you can enable Desktop and My Documents Folder redirection. This will redirect users Desktop’s and My Document’s folders to a network share. On local computers on your network, the computers will retain a cached copy for performance.
If you deploy an RDS Server and have Folder redirection configured, the users My Documents and Desktop will be available to that user. Additionally since the server is on the same network as the share hosting the data, the RDS server will not retain a local cached copy (saving space).
If you are considering implementing and turning on Folder Redirection, I would recommend doing so before deploying an RDS Server (especially before a user logs in for the first time).
Anti-virus and Endpoint Protection
Careful consideration must be made when choosing the antivirus and endpoint protection software for your RDS environment.
First, you must make sure that your antivirus and/or endpoint protection vendor supports Remote Desktop Services, and then also deploy their recommended settings for that type of environment.
A proper endpoint protection solution should run few processes for all users, and not individual processes for each user.
For continued service delivery, your IT staff must monitor and maintain the server. This includes monitoring logs, updating it via Windows Update, and updating the various applications your users are using.
As the environment grows, you can deploy additional RDS Servers and create an RDS Farm. If you get to this point you’ll be able to deploy a load balancer and grow as more performance is required, or additional users are brought online.
Deploying a Remote Desktop Services server is a great way to get a large number of users online and working remotely in a short amount of time. This keeps management happy, employees happy, and maintains a productive workforce.
As I mentioned, there are numerous other technologies so depending on what your company has already implemented or is using, may change what solution would be best for you.
If you have any questions or require help or assistance with deploying Remote Desktop Services for your organization, don’t hesitate to reach out to me!
With over 50 Small Business Server migrations under my belt, I can assist, perform, and provide consulting services if your company or organization is looking to migrate from Microsoft Small Business Server to a new platform.
While us pros usually stay away from this tool, it is needed sometimes. Recently I found myself in a situation where I wanted to run the “Disk Cleanup” Windows app, on a Windows Server 2019 VM running Server Core.
As you all know, Server Core has a limited GUI. You’re able to run things like a command prompt, Task Manager, notepad, and other limited things. I wanted to see if we could get Disk Manager running on it, because of it’s light UI I was thinking it may be possible.
How to install Disk Cleanup (cleanmgr.exe) on Windows Server 2019, Server Core edition
Two files are required for Disk Cleanup:
cleangmgr.exe – The Disk Cleanup executable
cleanmgr.exe.mui – I’m assuming this is the language files required for the application
The above files when installed, are stored here:
When it comes to installing Disk Cleanup, you need to have those two files placed in their appropriate directories.
You can source these files from other servers (preferably running the same version of Windows Server), or you can snag the files from the WinSXS folder on a valid Windows install. An example of the WinSXS paths can be found below:
Yesterday, December 12th 2019, I powered on my Windows 10 1909 workstation to see that the start menu wasn’t working, along with the notification tray. I could launch programs from the taskbar, but search, start, and notifications were not functioning.
Attention: If you are experiencing issues with search, please continue reading to the bottom of the blog post and the update marked February 5th, 2020.
Since my workstation is running as a VDI instance, I checked vSphere and noticed the VM was running at extremely high CPU. Inside of the workstation, I opened up the event log and found numerous errors pertaining to the User Shell Experience, as well as multiple Windows 10 apps (UWP apps).
I tried to troubleshoot this using multiple methods found online on google. It sounds like this is a common issue for the past couple months, but no one has been able to find a fix.
Finally, after 14 hours of frusteration, I finally decided to restore the workstaton (VM) from a snapshot backup the night before. Powering it on the start menu was working. I installed some updates and everything is still working great.
If anyone has any information on this, please post it in the comments! I was surprised this isn’t easily fixable and actually required a restore from backup. I’m assuming numerous others are experiencing this issue.
Today I’m going to be talking about Read Only Domain Controllers (RODC). An RODC is a Read Only Domain Controller for Active Directory Services inside of Microsoft Windows Server. It has become one of my favorite discoveries in the last 10 years for use with clients in certain situations.
A Read Only Domain Controller is similar to a regular Domain Controller, with the exception that the content is synchronized and available as a read-only copy. You cannot write to an RODC AD database.
Let’s explore RODC’s in more depth and find out what they are, why they are used, and use-case scenario examples.
What is an RODC
Read Only Domain Controllers were originally released with Windows Server 2008, and have been available on all versions since (including Windows Server 2008R2, Windows Server 2012/2012R2, Windows Server 2016, and Windows Server 2019).
A Domain controller that is an RODC contains a read-only cached copy of the Active Directory database. Additional sets of controls are available to control and limit this information and what is stored and cached.
Why an RODC
A Read Only Domain Controller is typically placed in situations and scenarios where a standard writable domain controller cannot be placed. The AD data/information can be filtered so that important items such as passwords, credentials, and other security sensitive information are not cached on that server. This provides a safety mechanism if the RODC is stolen or compromised (either physically, or virtually). You can control it so that only required information is cached, such as credentials for the users in the specific office.
RODC’s are meant to be used at remote offices and/or branch offices (ROBO) to allow services to function that rely on Active Directory such as file/print services and other Active Directory applications. Also, typically at these sites it either wouldn’t make sense or be safe to have a writable domain controller, however the RODC is needed to cache AD information, and enhance performance of these AD applications.
Offloading Active Directory requests to a single cached copy onsite on an RODC significantly reduces bandwidth pipe requirements versus having numerous computers and users authenticating and requesting Active Directory content over a site-to-site VPN between the main office and remote office/branch office.
Also, if you have an office with an unstable internet connection where the site-to-site VPN regularly has issues or isn’t always available, having an RODC available to handle Active Directory requests can keep that office online and functioning.
Scenarios for an RODC
In the past I’ve used Read Only Domain Controllers for a few different types of scenarios. I’ll get in to them below and explain why.
AD Cache for ROBO (Remote Office Branch Office)
Unstable internet connection
AD Services at remote site (File/Print, LoB)
Numerous Users accessing Active Directory
Improve login times
ROBO with Potential Security issues (theft, lack of survailence, etc.)
Office is in remote area with delayed physical security response, risk of theft
Server physical security at risk, employees could have access
Corporate Infrastructure hosted in the Cloud
Domain Controller in the Cloud
Need a DC on-premise to handle logins and resource access
AD Cache for ROBO (Remote Office Branch Office)
Implementing an RODC in this situation is an excellent example. In a situation where an office has unreliable (intermittent or slow) internet but is critical to business continuity, an RODC can keep them up and running uninterrupted.
Typically, if you were just using a Site-to-Site VPN, if that connection went down, users wouldn’t be able to authenticate against Active Directory or access resources in Active Directory. Having an RODC on-site, allows them to authenticate (if their credentials are stored) and access resources.
As most IT professionals are aware, having a large number of users authenticating and accessing these resources over a VPN can use up the bandwidth pipe and cause issues. Having an RODC locally virtually eliminates VPN bandwidth usage to only Active Directory synchronization, and synchronization deltas.
Finally, having users authenticate locally instead of a saturated high latency VPN connection, improves their login time and performance.
ROBO with Potential Security issues (theft, lack of survailence, etc.)
If you have a remote site with security concerns, an RODC can help you with your security strategy.
If an RODC is physically stolen, only credentials that are filtered to be cached on that RODC are stored locally, this usually excludes administrative accounts as well as other users and services that aren’t accessed or used at the remote site. Also, because the domain controller isn’t writable, the thief cannot power on, inject data in to Active Directory and have it sync to your other domain controllers if they somehow gained access to your internal network.
The above also holds true for possible malicious employees who may have skills or knowledge, or allow other 3rd parties to have physical or virtual access to the server.
In the event of a disaster, restoring or recreating an RODC is easy and fast. Since it synchronizes from writable DCs on the network, the concerns of traditional writable domain controller restores don’t need to be considered.
Corporate Infrastructure hosted in the Cloud
If by chance most of your corporate infrastructure is hosted in the cloud, you know that you still need some on-premise resources and infrastructure to handle and offload bandwidth requirements between your LAN network and virtual cloud LAN network.
Typically, in most cases you’d have an on-site on-premise domain controller to handle local login and authentication, as well as resource access. But why use a fully writable domain controller, when you can use an easy to manage and maintain RODC?
Using an RODC at your local site allows you to offload services off the pipe, to the RODC, again limiting bandwidth requirements to AD synchronizations and delta synchronizations. This allows your bandwidth to be used for more important things like Line of Business applications, e-mail, etc.
As most IT professionals prefer simple and functional, this keeps simplified and easy to manage.
RODC’s are a perfect tool to compliment your IT infrastructure and help secure it as well. I’ve placed numerous Read Only Domain Controllers at customers branch offices, remote oil and gas sites, and in various other scenarios.
Not only have they kept these customers up and running during outages, but the ease of use and ease of management make it common sense to use this technology.
Today I wanted to do a brief post addressing Microsoft Exchange Backup and Disaster Recovery.
In the past week I’ve had over 30 people reach out to me via chat looking for help and advice in situations where:
A Cumulative Update Failed
Exchange Services will not start
Hardware Failure Occurred
In all of these cases the admins took a snapshot of their Exchange virtual machine (in Hyper-V or ESXi/VMware), and then restored it to the previous point when the failure occurred. This completely broke their Exchange install and possibly made it unrecoverable.
Exchange Server supports only Exchange-aware, VSS-based backups. Exchange Server includes a plug-in for Windows Server Backup that enables you to make and restore VSS-based backups of Exchange data. To back up and restore Exchange Server, you must use an Exchange-aware application that supports the VSS writer for Exchange Server, such as Windows Server Backup (with the VSS plug-in), Microsoft System Center 2012 – Data Protection Manager, or a third-party Exchange-aware VSS-based application.
You must use an Exchange-aware backup and/or disaster recovery application/software suite. These applications are aware of Exchange and designed to perform proper backups of Exchange, the mailboxes, and configuration. Not only do they backup the mailbox database and the VM running Exchange, but they also backup the system state and configuration of Microsoft Exchange.
Simply performing a VM snapshot is not supported and can break your Exchange installation.
Note that the configuration for Microsoft Exchange is stored inside of Active Directory, and not on the actual Exchange Server. Restoring the Exchange Server to a previous snapshot will cause a configuration synchronization gap between the Active Directory configuration and the mailbox database on the Exchange Server.
Options for Backup
There are plenty of options to perform Microsoft Exchange-aware backups.
If you’re looking for something free and easy, you could use the built-in Windows Server Backup function on Microsoft Windows Server. It’s perfect for special migration and upgrade jobs, homelabs, and small/micro sized businesses.
For larger organizations, I’ve used, setup, implemented, and managed the following backup applications:
There’s no excuse for not having a backup, especially if you call yourself a professional. You should always have a full working backup, especially before performing any type of maintenance, updates, or upgrades to your environment.
Microsoft Exchange Issues and Failures
Additionally, in the event of an issue, the solution isn’t always to restore from backup.
In most cases when something fails, it’s best practice to troubleshoot and correct the issue, instead of blasting away Exchange and restoring from backups.
Most Exchange installs can be saved simply by following standard troubleshooting procedures. Even if an Exchange Cumulative Update fails, you can fix what caused it to fail, and then re-run the installer/upgrader to attempt to recover! No backup restore needed!
You may find yourself unable to download attachments on an e-mail message you received on your Android or Apple iPhone from your Microsoft Exchange Server. In my case, this presented a “Unable to download.” with a retry option. Retrying would not work.
If the attachment is larger (over 10MB), this is most likely due to a limit enforced on the Activesync site in IIS on your Exchange Server. In this post I’m going to tell you why this happens, and how to fix it!
Microsoft Exchange uses IIS (Internet Information Server) for numerous services including ActiveSync. ActiveSync provides the connectivity to your mobile device for your Exchange access.
IIS has numerous limits configured to stop massive bogus requests, reduce DDOS attacks, and other reasons.
To resolve this and allow the attachment to download, we need to modify two configuration values inside of the web.config file on IIS.
Below are the values we will be modifying:
MaxDocumentDataSize – Maximum file (message) data size for transfer. “Sets the maximum data size that we will fetch (range or othewise)”
maxRequestLength – “Specifies the limit for the input stream buffering threshold, in KB. This limit can be used to prevent denial of service attacks that are caused, for example, by users posting large files to the server. The default is 4096 KB.” (as per here)
These settings are configured in the following file:
Privacy & Cookies Policy