One of the most widely used applications suite is Microsoft Office, particularly Microsoft Office 365.
In order to deploy Microsoft Office 365 in a Remote Desktop Services environment, a number of requirements must be met. There is also special instructions which must be followed to properly deploy it.
After reading and completing the steps in this blog post and deploying Office 365, you can head over to my guide on how to Configure Office 365 in a Remote Desktop Services Environment using GPOs to pre-configure Microsoft Office and it’s applications for when your users log in.
What’s required
To deploy Microsoft Office 365 on a Remote Desktop Services Server, you’ll need:
A Remote Desktop Services Server (Configured and Running)
Microsoft 365 Apps for Enterprise (formerly named as Office 365 ProPlus)
Licensing
Special attention must be paid to licensing. In order to properly license and activate Office 365, you’ll need one of the following products that supports Shared Computer Activation:
Microsoft 365 Apps for Enterprise (formerly known as Office 365 ProPlus)
Microsoft 365 Standard, Office 365 Business, Office 365 Business Premium, and Office 365 Business Essentials cannot be used as they do not include or support Shared Computer Activation.
An exception is made for Microsoft 365 Business Premium which actually includes Microsoft 365 Apps for Business, but doesn’t support enabling “Shared Computer Activation” via Group Policy Objects and must be done using the XML configuration file method.
Installing Office 365
Once you have the proper licensing and you’re ready to proceed, you can start!
To download the 32-bit version or enterprise version, use one of the other xml files that are in the directory.
There will be no output and it will take a while so be patient.
Now we want to open the xml file we previously used (in our case “configuration-Office365-x64.xml”) and add the following lines to the file right above the final line (right above </Configuration>):
Office 365 should now install silently, and then afterwards you should be good to go!
When a user logs in for the first time it will ask them to activate on their account. The user must have a license attached to their Office 365 account.
I found out today that some time ago, the G729 codec was released from all patents, and is now available free of charge to use on FreePBX (and probably Asterisk).
On fresh installation of the FreePBX SNG distribution, the G729 codec is pre-installed and ready to go out of the box, however if you have an older system that you have been maintaing and upgrading, G729 is not automatically installed.
As of version SNG7-PBX-64bit-1712-2 (with FreePBX 14.0.1.22) which was released on December 21st, 2017 the codec is included.
Open Source G729 codec is now present on installation
Older installations can activate it with the 'g729' command
How to install G729
If you have an older install that you have been updating to the latest release, as per the release notes you must run the “g729” command. This will tell you if it is, or is not installed. If it is not installed, it will advised you to run the “yum -y install asterisk13-g729” command.
I ran the commands and installed the G729 codec on my system running SNG7-PBX-64bit-2002-2 (FreePBX Version 15.0.16.42, OS Version: 12.7.6-2002-2.sng7).
[root@pbx01 ~]# g729
The Open Source G729 code is not installed.
You can install it with the following command:
yum -y install asterisk13-g729
[root@pbx01 ~]# yum -y install asterisk13-g729
The package then installed, I restarted the PBX, and g729 was available to use. I tested and it works great!
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
Microsoft 365
Skype for Business
Microsoft Teams
Zoom
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.
What’s required
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.
Remote Desktop Services servers are often under attack on the internet. You’ll find that the servers are subjected to scans, brute force attempts, and exploit execution. You’ll want to make sure that you have both a firewall (with intrusion prevention) and a security technology like DUO Security Two Factor Authentication configured to protect your server.
Finally, you’ll need a static IP on the internet and a friendly DNS hostname for your employees to connect to using the Remote Desktop Protocol (RDP) Client, such as “remote.companyname.com”.
Deploying RDS
Deploying RDS is easy. Here is a brief summary of the steps to rapidly deploy a Remote Desktop Services server for remote access.
Install Windows Server on the server or virtual machine that will host RDS.
Configure networking (static IP) and join to domain.
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.
Test the environment
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.
As mentioned above, your RDS server will be subject to ongoing attacks. These attacks include vulnerability scans, bruteforce attempts, and targeted exploitation attempts.
You’ll want to make sure that you have and enforce strict password policies to stop bruteforce attempts.
A firewall should be implemented that includes an intrusion prevention system to identify and stop intrusion attempts.
You should implement two factor authentication using a product like Duo from Duo Security.
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.
Duo Security Two Factor Authentication on Remote Desktop Services RDS Demo
Optimizations
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.
Folder Redirection
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.
Service Delivery
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.
Software Installation
When installing software on your Remote Desktop Services Server, extra steps must be taken so that the registry is properly handled for the multi-user environment.
Before launching a software installer, open a command prompt (elevated as Administrator) and run the following command:
change user /install
This will change your user session to an install mode. You can now run your software installation.
After the software installation is complete, put the RDS Server back in to execution mode with the following command:
change user /execute
Performing the above will make sure that the registry is properly handled during software installation for proper functioning of software in a multi-user RDS environment. Restarting the server will always automatically bring it back up in execute mode.
Conclusion
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!
When you start getting in to complicated setups with VLANs, multiple subnets, etc… Planning your UniFi deployment can get tricky.
I’ve had numerous readers reach out after reading my Ubiquiti UniFi Review and ask questions about their UniFi adoption issues, as well as what the best method is.
I regularly see IT professionals adopting via SSH or the mobile app, however in best practice and large deployments you want this to be automated and require as little human intervention as possible.
All an IT administrator should have to do is connect the device to the network and see it in the UniFi Controller. This should apply to the most simplistic, as well as the most advanced deployments.
Design
If you’re using multiple subnets and multiple VLANs, you need to make sure that when a new UniFi device (such as an Access Point or Switch) is connected, that the following two things occur:
It can get an IP address from a DHCP Server
It can reach out to a UniFi controller (we’ll get in to this more in a bit)
In more complicated environments, your UniFi controller may be sitting on a different VLAN and you may also have your management VLAN on a different VLAN as well (where your UniFi devices reside after adoption).
My Environment
UniFi Devices Adopted in the UniFi Controller
In my environment, the following is true:
No devices except a DHCP/DNS server and firewall/router sit on the untagged VLAN of 1.
My UniFi devices (including controller, Access Points, and switches) have a separate dedicated management VLAN.
The purpose of having an untagged VLAN of 1 is to allow provisioning of devices that self or auto provision. This network is an isolated network that is heavily controlled via the router and firewall that is running IPS (Intrusion Prevention System) and strict firewall rules.
Normally I wouldn’t even have anything on the untagged VLAN of 1, however a provisioning network is needed. For example when you plug in a UniFi NanoHD, or a UniFi Switch, it’ll grab an IP on the untagged VLAN of 1, and look for a controller to present itself to for adoption.
Best Adoption Method
No matter how simple or complex the environment is I always recommend using the DNS method of adoption.
Most networks have DHCP and DNS, whether it’s for workstations, servers, or IT infrastructure. It’s extremely easy to setup a DNS Host (A) record or an Alias (CNAME) record of “unifi” and have it point to your UniFi Controller.
If you’re using multiple VLANs and subnets, your network must be fully routable from the untagged VLAN of 1, all the way to your UniFi controller.
I highly recommend putting strict firewall rules in place to only allow communication to the UniFi Controller from the untagged VLAN 1.
Conclusion
Following these practices allow you to simplify your UniFi deployment even on extremely large and complex networks, while not straying from keeping your network secure!
Everything is automated, efficient, and ready to use!
During a previous project I needed to create a fresh and clean boot partition for a Raspberry Pi. I needed to create the partition layout required for the Raspberry Pi to see and boot a Linux kernel from.
There are many guides on the internet on how to write a Raspberry Pi image (which includes the system-boot partition), but I wanted a clean and fresh partition layout, without the additional partitions containing the Linux operating system.
I was creating a new Micro SD card with the purpose of using an NFS Root for the Raspberry Pi. For those of you that don’t know, you can boot a Raspberry Pi (or Linux computer) from local media, whether it’s a CD, USB Stick, Micro SD, or hard drive, and then have the actual operating system root file system be loaded via NFS. You can also use PXE to boot the kernel requiring no local storage, but that’s beyond the scope of this article.
Raspberry Pi default Partition layout
Below, we’ll look at the default partition layout you’d see on a Raspberry Pi using a prebuild linux image.
Disk /dev/sda: 59.6 GiB, 64021856256 bytes, 125042688 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x97709164
Device Boot Start End Sectors Size Id Type
/dev/sda1 8192 532479 524288 256M c W95 FAT32 (LBA)
/dev/sda2 532480 125042687 124510208 59.4G 83 Linux
I’m using a USB to Micro SD adapter to view the partitions on this card, so it’s being presented to the system as “/dev/sda”. On a normal computer “/dev/sda” is the first hard drive (usually the OS) so be careful when using these commands.
You’ll notice that “/dev/sda1” is the Raspberry Pi boot partition, with an Id of 3, and has the type of “W95 FAT32 (LBA)”.
The second partition which is the filesystem root (which I moved to NFS), is “/dev/sda2”, with an Id of 83, and has a type of “Linux”.
Creating a fresh partition layout with only the boot partition
In this guide we’re going to setup a Micro SD card with a fresh boot partition for the Raspberry Pi from scratch. We are not using an image and we are not using the expansion feature.
We’re going to assume that your destination SD card is empty. If it isn’t, you’ll need to delete all the partitions using “fdisk /dev/device”, and then deleted them with “d”.
Alternatively, to delete existing partition information you can wipe the MBR and partition table with the following command. Replace “/dev/device” with the actual device label for the card. Note that this will render existing data useless and unrecoverable.
dd if=/dev/zero of=/dev/DEVICE bs=512 count=1
Please Note: Make sure you are running this command on the right device. Afterwards, unplug and re-insert the SD card.
Creating the layout
On an empty Micro SD card:
Open fdisk on your card.
fdisk /dev/sda
Press “n” to create a partition.
Press “p” to make it a primary partition.
Press “1” to make it the first partition in the table.
Press <enter> to accept the default on start sector.
Type +size to choose the size. In my case I want 1GB, so I’ll type “+1G”.
After it’s created, press “a” to make it bootable.
Now we press “p” to print and view the partition table, as shown below.
Command (m for help): p Disk /dev/sda: 3.7 GiB, 3965190144 bytes, 7744512 sectors Geometry: 122 heads, 62 sectors/track, 1023 cylinders Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x4eb27b84 Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 2099199 2097152 1G 83 Linux
Now we need to set the partition type. Press “t” to set a partition type, choose the partition, and type “c” for “W95 FAT32 (LBA)”.
We’re now left with this partition table.
Press “w” to write and save, and exit fdisk.
We now need to format the partition. Run the following command on your device.
mkfs.vfat /dev/sda1
Finally, you can now set a label to the partition. Ubuntu uses the label “system-boot” whereas Raspbian uses “boot”. You can set it with the following command:
fatlabel /dev/device NEW_LABEL
You now have a clean partition layout that can be used to boot a Raspberry Pi. Remember that this is just the partition layout and the files are still needed from an image or your current running instance. These can simply be copied over.
In my case, I just mounted an old and the new partitions to directories and copied the data over. This allowed me to modify the new boot partition and ultimately make it boot in to an NFS root.
If you need just a simple boot partition, you don’t need to purchase large Micro SD cards.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.
Do you accept the use of cookies and accept our privacy policy? AcceptRejectCookie and Privacy Policy
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
