Can’t get into the vCenter VAMI via the root account? The 90-day password expiry policy is likely to blame. Here’s how to reset your password.
A few years back, VMware implemented a password expiry policy of 90 days for the root account on the vCenter Server appliance. Although this account isn’t used much once vCenter is up and running, you do require it for VAMI access or to login via SSH. Administrators frequently use the VAMI for vCenter upgrades, so you will inevitably run into this problem sooner or later.
In vCenter Server 7.x the error message you receive will be:
Exception in invoking authentication handler User password expired.
For those not familiar with the CLI access options in vCenter Server, you may head over to the “Users and Groups” section in the vSphere client to look at “localos” domain accounts where root is located. You won’t be able to manipulate this account from the vSphere Client and the account will not be listed as “locked” or “disabled”.
Thankfully, resetting your password is a piece of cake via CLI. SSH should be enabled by default for your vCenter Server. Simply login using your favorite SSH client and you’ll be greeted by a password change prompt:
Changing your password may be an exercise in frustration as this prompt will prevent you from using similar passwords and enforce some complexity requirements (see how to get around this below). Once you’ve changed the password, you’ll be able to login to the vCenter Management Interface (VAMI) again.
If this is an isolated lab environment – don’t do this in production – and you don’t want to change your password, you can set a temporary password and then change it back via the root shell as follows:
Command> shell Shell access is granted to root root@vc [ ~ ]# passwd New password: Retype new password: passwd: password updated successfully root@vc [ ~ ]#
Verify how long you’ve got till your password expires again by using the chage command:
root@vc [ ~ ]# chage -l root Last password change : Mar 05, 2021 Password expires : Jun 03, 2021 Password inactive : never Account expires : never Minimum number of days between password change : 0 Maximum number of days between password change : 90 Number of days of warning before password expires : 7
And there you have it. Hopefully you found this helpful.
A new 6-bay AMD Ryzen powered NAS unit from Synology with lots of potential!
My very first commercial NAS box that I bought over 13 years ago was the dual-bay Synology DS207+. At the time, it was the cream of the crop. The hardware was great, but Synology’s very rich software suite was what really set it apart from many of its competitors at the time. The unit served me very well for years in my home network.
Once I got my first VMware home lab setup, I moved away from consumer-grade NAS units and toward more powerful custom-built servers running FreeNAS/TrueNAS. Although awesome for home use, the SoC (system on a chip) ARM-based processors on these old units simply couldn’t handle the I/O requirements for VMs on iSCSI or NFS datastores. Unless you were willing to shell out a lot of dough for an enterprise-grade NAS/SAN, you were stuck building your own. A lot has changed in this market over the last few years. NAS units have gotten much quicker and a reasonably priced unit can now be a very feasible solution for a wide variety of applications – including virtualization. Today, Synology makes a number of multi-bay NAS units with powerful processor options. They have everything from high-performance ARM based units to Xeon-Ds and even AMD Ryzen Embedded options as in the 1621+. Although they still command a premium price, you get way more for your dollar today than you did even just a few years back. When Synology asked if I would be interested in trying out one of their business class “plus” NAS units, I jumped on the opportunity.
Synology was kind enough to send me a review sample including a DS1621+ NAS unit, three of their Synology branded 8TB hard drives and their new E10G21-F2 10Gbps SFP+ NIC. Over the next few weeks, I hope to take a look at this latest generation of multi-bay NAS systems and see how feasible they are for a small to mid-sized business network. I’m also very interested in trying out some of Synology’s included software that is catered towards VMware vSphere. For now, I just wanted to share a quick unboxing and hardware setup post.
Power Consumption: 51W (Access), 25W (HDD Hibernation)
Warranty: 3 Years
The specifications for this NAS unit are quite impressive. The one feature that gets most people excited is the embedded AMD Ryzen processor. With AMD’s hugely successful Zen architecture, this is not surprising. AMD has managed some very impressive performance numbers – especially in their 3rd and 4th generation CPUs. Being an embedded part, the Zen V1500B processor is a little different than their desktop processors. From what I can see, it is based on AMD’s first generation Zen architecture so it won’t be quite as potent clock-for-clock as some of AMD’s recent Ryzen CPUs. None the less, with four cores, eight threads and a 2.2GHz clock speed, this is a very capable CPU for a NAS. Best of all, being an embedded part, the total TDP for this processor is only 16W. Having a potent x86-64 CPU under the hood opens up the possibilities for a number of different use cases. Not only should iSCSI storage performance be up to the task, but you could even run virtual machines and many of the more demanding software packages on the NAS unit.
Another great feature is Synology’s inclusion of NVMe. Three and a half inch mechanical drives do still have their place for affordable raw storage capacity, but flash storage is really necessary for good performance. All six drive bays support 2.5 inch SATA SSDs, which is great, but there are now two NVMe slots intended to be used for drive caching as well. Being able to use multiple storage tiers and caching really gives this NAS a lot of performance potential.
Without further ado, let’s check out the DS1621+ and the other goodies Synology sent over.
Synology moved away from flashy packaging years back. I like the subtle cardboard packaging because it lets the quality of the product speak for itself.
The size of the box makes the NAS unit feel larger than it actually is. There is ample protection from shipping damage with foam protecting the unit from all sides. The NAS itself is wrapped in plastic to keep dust out.
A small cardboard box includes a pair of high quality ethernet cables and a standard power cable. A small bag of screws and the drive bay keys are also contained within. From what I can see, the screws are only needed for mounting 2.5-inch drives.
The unit itself has a heavy, high quality feel to it. The outer shell and back panel are metal and only the front panel and drive bays are constructed of plastic. Six hotswap SATA drive bays are accessible from the front of the unit. Two 92mm fans dominate the back and line up perfectly behind all six drive bays and should provide good directed airflow.
There are two USB3 ports at the rear (and one at the front) as well as four 1GbE NICs and a pair of eSATA connectors. The eSATA ports can be used for Synology’s expansion units. With two DX517s, you could have up to 16 drives in total.
Synology was kind enough to include three of their self-branded 8TB HAT5300 mechanical drives with the NAS unit. From what I can see, these are manufactured by Toshiba and are 7200RPM models. Synology supports a large number of mechanical drives from a variety of manufacturers, but supplying their own removes the guess work that customers need to do and guarantees 100% compatibility.
Since I plan on using this NAS in my VMware home lab, 10GbE networking will be essential. Synology provided me with their brand new E10G21-F2 SFP+ card. Synology supports a pretty long list of 10Gbps NICs on some of their older NAS units, but the list is short for the DS1621+ at this time. I suspect they are still testing cards for compatibility as this NAS is still quite new. Similar to their branded HDDs, going with a Synology branded NIC ensures 100% compatibility. Synology sells 10Gbase-T models as well if you aren’t using SFP+ DACs or optics.
The perfect Raspberry Pi 4 case to use for VMware’s ESXi on Arm fling. It doesn’t get much better than this.
I’m a bit late to the party, but I finally picked up a Raspberry Pi 4B 8GB board to use with VMware’s new ESXi on Arm technical preview. I initially tested it without a case, and a small USB 3.1 flash drive. It wasn’t long until I realized the system was pretty much unusable without decently performing storage attached. It did a lot better with an external USB drive I had lying around, but I didn’t like the mess of cables and having devices larger than the Raspberry Pi attached just seemed wrong.
After looking around for a suitable case, I was immediately drawn to Argon Forty’s new Argon One M.2 case.
I had seen the original Argon One, which ticked many of the right boxes, but this one adds one feature I really wanted – built in storage. As the name implies, there is an M.2 SATA storage adapter that is enclosed within the case. If you have already bought an Argon One, you can buy the M.2 bottom kit as a standalone option to convert yours as well!
Along with the Argon One M.2, I purchased their 18W 5.25V power supply, which came highly recommended. I also picked up a very inexpensive 240GB M.2 SATA drive on Amazon made by Asseno. The case itself is comprised of a top and bottom shell with attached circuit boards. An additional board is included that attaches to the Pi as well as a USB to USB bridge.
A small circuit board attaches to the ports at the side of the Raspberry Pi and redirects them toward the rear. I absolutely love this feature as the default placement of ports on the Pi can make wiring a bit of a mess. As an added bonus, the adapter converts the two micro-HDMI ports to full size HDMI connectors. The larger connectors are a much more popular connector type, and this could save you from having to buy a micro-HDMI cable or adapter. You’ll also notice that the USB Type C power connector is not attached and left unused. This is because power input is provided through the pin bank once the top of the case is attached.
Windows server licenses aren’t cheap so why not pair your AD domain controller with a Linux BIND9 secondary instead? Find out how!
Having a backup for your Windows Active Directory DNS services is always a good idea. Larger organizations would probably have a backup domain controller providing secondary DNS duties, but this may not be feasible for small shops or home labs. Windows server licenses aren’t cheap so why not pair your AD domain controller with a Linux BIND9 secondary instead?
I ran a home lab with a single DNS server for years, but I got into a few situations where it became problematic. To conserve power, I shut down the majority of my home lab, including the hosts that run my Active Directory VM. I wanted to maintain DNS functionality for the limited number of VMs that stay powered up 24/7. Having a functional secondary was the answer.
What is a DNS Slave?
I don’t like the dated DNS terms “slave” and “master” but to avoid any confusing terminology changes, I will stick with this naming. A DNS slave is essentially a server containing read-only copies of DNS zones received from a DNS master server. All of your “A”, “MX” and other records are configured in the zones of the master and then are sent to the slave using “zone transfers”. In practice, the slave zones should always be identical to that of the master. If the master goes down, clients will still be able to resolve DNS queries via the slave. Obviously, in order for this to work, all of your client devices and VMs will need to have both DNS servers defined in their TCP/IP configuration.
Configuring Your Windows DNS Server
Before you can do zone transfers to your new secondary, some configuration will be required on your Active Directory DNS server. I’m using Windows Sever 2018, but this should be the same for 2012/2016 and even 2008 if I’m not mistaken.
Before changing any configuration, you’ll need to create a standard “A” record for your secondary DNS server in your forward lookup zone. In my case, it is ns2.vswit.ch with an IP of 172.16.10.11:
Next, from the DNS snap-in, right click on your DNS server and go to Properties and click the Advanced tab.
One common thing I find myself needing to do in Linux bash shell scripting is to check if a file or directory exists. The opposite is equally important – to see if a file does not exist. This can be used to check if a previous install or config has been done or not, or to check for certain conditions.
This is done using the Linux “test” command and is generally done in conjunction with a simple “if fi” statement with some action taken as a result. There are several file operators that can be used with test, but the most common are -f for standard files and -d for directories. There is also -e that will check for any type, including non-standard files (think devices listed in /dev for example) as well as directories. You can find a full list of file operators on the test man page.
It is important to understand that the test command will not output anything to stdout – it relies on exit codes to report a success or failure. For the purposes of file and directory checks, an exit code of 0 is “success” and 1 if “failure”. To see the exit code of the last command run, you can use echo $?.
Check if a file /opt/guest-cust/readme.md exists:
test -f /opt/guest-cust/readme.md echo $? 0
Because an exit code of 0 was returned, we know that the file exists.
The utility “cron” is a job scheduler in Linux/Unix based operating systems. It is very useful for scheduling scripts or specific commands to run on a defined schedule – daily, weekly, monthly and everything in between. Thankfully, ESXi includes an implementation of the cron utility that can be accessed from the root shell. Normally, you wouldn’t need to use cron, but there are some situations where scheduling CLI commands can be useful.
A few use cases where I’ve personally done this over the years include:
To collect switchport statistics at certain times overnight to troubleshoot packet loss or performance issues.
Restarting a specific service every 24 hours to prevent a memory leak from getting out of hand.
Executing a python or shell script to collect various data from the CLI.
ESXi’s implementation of cron is similar to that of most linux distributions, but it is not exactly the same. The popular ‘crontab’ command isn’t included and can’t be used to easily add jobs. In addition, any cron changes you make won’t take effect until the crond service is restarted.
Before changing the cron configuration, you’ll want to test the command or script you plan to schedule. In my case, I’m going to simply run an esxcli command every two minutes that will add a mark entry into the system log files:
[root@esx1:~] esxcli system syslog mark --message="My cron job just ran!"
[root@esx1:~] cat /var/log/vmkernel.log |grep "mark:"
2021-02-17T17:39:00Z esxcfg-syslog: mark: My cron job just ran!
As you can see above, this is a great way to test out cron because every time it runs you’ll get proof in the logging along with a date/time stamp.
Also, if you are not familiar with crontab formatting, I’d recommend reading up on the subject to make sure your jobs run as expected. There are a number of good resources online that will show you the various scheduling options. I have included a few examples at the end of this post as well.
Adding a Cron Job
You’ll first need to SSH into your ESXi host. Once there, you can see the current crontab file at /var/spool/cron/crontabs/root. In ESXi 7.0, the file contains:
You can modify the file using ‘vi’. For those not familiar with Linux, there is a bit of a learning curve to vi so I’d recommend reading up on how to navigate around in it. There are quite a few good turorials available online.
[root@esx1:~] vi /var/spool/cron/crontabs/root
Note: When using :wq to save your changes, you’ll likely get a warning that the file is read only. You don’t need to fiddle with the permissions. Simply use :wq! and the file will be written successfully.
I have added a single line at the bottom of the file. Here is the updated root crontab file:
You’ll know it was restarted successfully if you have a new PID now:
[root@esx1:~] cat /var/run/crond.pid 2103414
After leaving the host idle for a few minutes, you can see the command has been running every two minutes as desired:
[root@esx1:~] cat /var/log/vmkernel.log |grep -i mark: 2021-02-17T17:39:00Z esxcfg-syslog: mark: My cron job just ran! 2021-02-17T20:16:00Z esxcfg-syslog: mark: My cron job just ran! 2021-02-17T20:18:00Z esxcfg-syslog: mark: My cron job just ran! 2021-02-17T20:20:00Z esxcfg-syslog: mark: My cron job just ran!
As you can imagine, the possibilities are endless here. I will share some of the scripts I have used to collect some performance metrics via cron in a future post.
Run a command every two minutes:
#min hour day mon dow command */2 * * * * esxcli system syslog mark --message="My cron job just ran!"
Run a command every hour:
#min hour day mon dow command * */1 * * * esxcli system syslog mark --message="My cron job just ran!"
Run a command at midnight every night:
#min hour day mon dow command 00 0 * * * esxcli system syslog mark --message="My cron job just ran!"
Run a command at 3:30PM every Thursday:
#min hour day mon dow command 30 15 * * 5 esxcli system syslog mark --message="My cron job just ran!"
Run a command at midnight and at noon every day:
#min hour day mon dow command 00 0,12 * * * esxcli system syslog mark --message="My cron job just ran!"
I’m always keeping an eye out for old parts on eBay. One of my saved searches, of course, is for the string “3dfx”. I’ve always had a soft spot for the original king of 3D gaming, but just about everything made by 3dfx is collectable and commands a hefty price premium these days. I usually try to steer clear of things marked “untested” or “for repair” but sometimes a deal is just too good to pass up.
When I came across this as-is, untested 3dfx Voodoo 2 for a great price, I decided to take a chance on it. It did show some obvious signs damage in the eBay listing pictures, including some visible scratches and a bent PCI bracket. I could also see some of the chip legs were bent, which can sometimes be tricky to get straightened out. I knew it would probably not work without a repair or two, but maybe I’d get lucky?
TLDR: Modify your power plan to ensure your VM isn’t going to sleep!
I had recently deployed a new Windows 10 based VM that would serve as an RDP jump box to access lab resources. Initially RDP worked fine, but I noticed that after a while I couldn’t connect any more. The only way to rouse it from this state was to open a direct console window from the vSphere Client, or to reboot the VM.
The exact error message from the Remote Desktop for Mac window is:
“We couldn’t connect to the remote PC. Make sure the PC is turned on and connected to the network, and that remote access is enabled.
Error code: 0x204”
In addition to the 0x204 error, I also saw “Error code: 0x4” numerous times as well.
The two error codes I kept getting (0x204 and 0x4) were not helpful and just led me on a wild goose chase. These codes were only reported on the Mac RDP client and Windows was more generic:
Clearly the message “Make sure the PC is turned on” garnered no attention from a seasoned IT professional like me, but in the end turned out to be relevant. The issue was that the Windows 10 VM was going to sleep.
I only noticed this when I saw a blacked-out screen in the console preview and the lack of a hostname or IP address listed. This tells me that VMware tools hasn’t checked in for a period of time.
I’m not sure if an incoming RDP connection attempt would wake a physical machine in this state, but sleep isn’t very beneficial to a VM. I simply modified the power settings to prevent sleep and hibernation and the issue hasn’t happened again.
Windows Server varieties don’t behave this way, but because Windows 10 is primarily intended for bare-metal laptop and desktop use cases, power saving features are enabled by default.
This is a pretty basic problem, but I thought I’d do a post just in case it helps someone else who overlooked the obvious like I did and instead tried chasing up hexadecimal error codes 🙂
If you are attempting to upgrade your vCenter Server and are getting stuck in stage one while connecting to the source appliance, a simple password change may get you going again. In my case, I was upgrading from vCenter 6.7 U2 to 7.0 but this could certainly occur with other upgrade paths as well. I got the following error:
“A problem occurred while getting data from the source vCenter Server.”
The error message is pretty non-descript, but we do get the option to download some logging. In the log file downloaded, it seems pretty clear that this is an authentication problem:
2020-04-12T20:13:55.435Z - info: VM Identifier for Source VC: vm-16
2020-04-12T20:13:55.568Z - debug: initiateFileTransferFromGuest error: ServerFaultCode: Failed to authenticate with the guest operating system using the supplied credentials.
2020-04-12T20:13:55.568Z - debug: Failed to get fileTransferInfo:ServerFaultCode: Failed to authenticate with the guest operating system using the supplied credentials.
2020-04-12T20:13:55.568Z - debug: Failed to get url of file in guest vm:ServerFaultCode: Failed to authenticate with the guest operating system using the supplied credentials.
2020-04-12T20:13:55.569Z - error: Failed to read the nodetype, Error: Failed to authenticate with the guest operating system using the supplied credentials.
2020-04-12T20:13:55.569Z - info: Checking if password expired
2020-04-12T20:13:58.915Z - info: Stream :: close
2020-04-12T20:13:58.915Z - info: Password not expired
2020-04-12T20:13:58.917Z - error: sourcePrecheck: error in getting source Info: ServerFaultCode: Failed to authenticate with the guest operating system using the supplied credentials.
Despite double checking that my credentials were correct, the logging insisted that there was something wrong with them. The logging also states that the password was not expired. Despite this, I decided to check anyway:
root@vc [ ~ ]# chage -l root
You are required to change your password immediately (root enforced)
chage: PAM: Authentication token is no longer valid; new one required
Well, that’ll do it. Looks like the root password was expired after all. I found it odd that it allowed me to login via SSH without any kind of password expiry warning. I changed the password using the ‘passwd’ root shell command.
root@vc [ ~ ]# passwd
BAD PASSWORD: it is based on a dictionary word
Retype new password:
passwd: password updated successfully
root@vc [ ~ ]# chage -l root
Last password change : Apr 12, 2020
Password expires : Jul 11, 2020
Password inactive : never
Account expires : never
Minimum number of days between password change : 0
Maximum number of days between password change : 90
Number of days of warning before password expires : 7
After changing the password from the CLI, the upgrade progressed normally! Hopefully this tip may help others that get stuck on this step as well.
The recent COVID-19 situation around the world has resulted in a large number of people having to work from home. Most in IT roles have had to work from home at one time or another due to illness, inclement weather or some other reason, but they generally don’t have to for longer than a few days consecutively. Having to work from home longer-term is a whole other ballgame in my opinion. Depending on your personality, it can be a really daunting prospect. Those that are very extroverted and strive on social interaction may find it difficult but if you are like me – more of an introvert – you may adapt more easily. Regardless of your personality-type, there are a number of things you can do to survive or even thrive at home. I decided to focus less on the technical aspects and more on the other side of the equation. Most people know that a laptop, good internet connection and VPN access is essential, but it’s the other things that aren’t always obvious.
I’ve got about four and a half years of working from home under my belt. During that time, I learned a few lessons along the way. Here are some tips for those of you finding yourself in this situation.
1. Maintain a Morning Routine
About two or three weeks into my WFH experience I found myself waking up later and later in the morning. Having a commute that involves nothing more than walking down the hall is great, but it eventually got to the point where I’d roll out of bed about five minutes before I had to be online. Believe me, this isn’t a great way to start your day and will make you feel crummy all day long. If you’ve got kids that you have to get ready for school, or if your significant other has to commute, this will be less of a problem for you. If not, be sure to give yourself at least an hour every morning to start the day off right. Make a decent breakfast, have your coffee and do all of the same personal hygiene related things you’d do before commuting to the office. Avoid working from home in your pyjamas and you’ll feel a lot better all day long.
2. Maintain a Proper Work Space
Sitting on the couch with your laptop and your feet up sounds great at first, but this simply isn’t a good idea long-term. It isn’t good for your posture, joints and health – and you simply won’t be as productive. At the very minimum, I’d recommend having a proper desk and high-quality office chair so that you can sit upright. Ideally, you should be using a keyboard, mouse and external monitor (or multiple displays) at the proper height. Another key piece of hardware to have with you at all times is a high-quality headset. Wireless is best as it’ll allow you to move around the house during calls. I was fortunate to be able to take home a great office chair and some 24” displays from the office and received some financial assistance to purchase a desk and other essentials.
3. Pick a Room to Call Your Office
This may not be possible for everyone depending on the size of your home or apartment, but if you can, find a quiet room or space that will be dedicated for home office use. Sticking your desk in the living room where your kids are watching TV at full volume and crawling all over you may not be the best place to setup shop. Considering using a spare bedroom, or a quieter corner of your home. Be sure the room is comfortable and well-lit, or you simply won’t work effectively. I don’t recommend sticking yourself in a dark, damp corner of an unfinished basement, even if it is quiet there. Having a dedicated room also helps you to mentally separate work from home, which is good for work-life balance as I’ll cover in another point.
4. Keep In Touch with Colleagues
The old saying “out of sight, out of mind” can be relevant to employees that work from home. When I was at the office, I worked with a large local team and also collaborated with colleagues all over the world. I was naturally more inclined to speak to the people around me than to reach out to colleagues at other offices. Suddenly, when I had to work from home, everyone was remote. There was no more local team that I saw every day. If you are not the social type, it can be important to find ways to keep in touch with your teammates. Remind everyone that you are still around. Pick up the phone and ask people what they are working on. If you were close at the office, keep in touch about what’s going on outside of work as well. Even if you are “out of sight” you need to make sure you are not “out of mind”. This will help you to continue to feel like a valuable part of the team and will help you to stay engaged.
5. Keep In Touch with Your Manager
This is similar to the previous point, but I wanted to make special mention here. Over the last few years, I’ve had several managers. Some were terrific at making the remote workforce feel like part of the team and others were not. If you start hearing about changes in the team from others or have missed out on special projects and opportunities you would have been interested in, this could be a red flag. Be sure that you are doing some “managing” yourself. Take the initiative to stay in touch with your manager to discuss the things you are working on. Make sure you are still having those one-on-one meetings and checking in regularly regarding your development goals. If your team doesn’t have regular team meetings, encourage your manager to get them setup. If your manager doesn’t make the effort to stay in touch with you, it’ll be up to you to ensure this happens.
6. Use Video Conferencing
Using the phone and instant messaging apps will always be part of the day to day, but video conferencing can be a great tool for the remote workforce. When my team started working from home, we would do multi-participant zoom video meetings just to chat and check in with each other. Seeing everyone face-to-face in their home offices was comforting because we knew we were all in the same situation. If you can’t meet in person, this is the next best thing. Over the years, technology has improved so much in this area. I remember back in the early-2000s how cumbersome and challenging video conferencing was to get going. Today it is readily available and simple to use. Take advantage of it! If you don’t already have a high-quality external USB camera, I’d recommend picking one up. They aren’t expensive and are much better for those with external monitor setups than the one integrated in the laptop.
7. Maintain a Healthy Work-life Balance
Not having to commute and being closer to family should – in theory – promote a much better work-life balance. Surprisingly, for some people, working from home can have the opposite effect. Sometimes you just get “into the zone” and the line between work and home gets blurred. It can be tempting to keep working past 5:00 just because you are already home. Or perhaps you’ll leave your laptop signed in to keep an eye on things. If you never go into the office, then you never left the office either – you may feel trapped in a perpetual state of work. This degree of availability may be expected in some roles, but if it isn’t, try to set boundaries between work hours and home hours. Consider powering off your laptop and only allowing critical alerts through on your phone should you be needed. Tell your colleagues to call you if anything urgent comes up instead of staying glued to your laptop. Believe me – it’s a lot easier to fall into this when you are at home versus commuting into an office.
8. Take Breaks and a Proper Lunch
This one could have been lumped in with the previous point, but I think it deserves special mention. Breaks and lunch are often social events. At the office, your colleagues may reach out to you to see where or when you want to go for lunch. There are queues to let you know it’s time to take a break – people start leaving the office, the smell of microwaved leftovers begins emanating from the break rooms. When you are working from home, you simply don’t get these reminders. When I first started, I would find myself skipping lunch, or taking breaks way too late, usually after mental exhaustion has already set in. Consider creating a calendar invite to remind yourself. Also, be sure to get away from your laptop for at least part of your lunch. Get up, stretch, take a walk. Don’t be tempted to simply grab some food and eat in front of your screen.
9. Get Some Daily Exercise
Working from home usually means you are moving less. It may not seem obvious, but when you commute you are doing a lot more walking. You walk to your car, from the parking garage to your office. Maybe up some stairs, or between buses or subway stations even. While at the office, you’ll probably also move around more – to the cafeteria, between buildings and to meeting rooms. There have been some clear scientific links between healthy mental function and physical exercise. If you are already out of your element working from home, find some ways to introduce some physical exercise into your routine. Take a walk around the block at lunch time, or simply get up and go up and down the stairs a bit. I have a treadmill in the basement that I try to use each day when time permits.
10. Enjoy the Benefits!
Last but not least, enjoy the many benefits of working from home! Once you overcome the challenges, you’ll begin to appreciate the benefits as time goes on. To be honest, I have become so accustomed to working from home that it would be very difficult for me to start commuting again. If you are able to create a functional workspace, effectively communicate with colleagues and keep a healthy work-life balance, you can be just as productive at home than you can at work. Depending on the type of work you do, I’d go so far as to say you can be even more productive. Don’t forget the financial benefits as well – less spent on petrol, car maintenance and transit. There are also some tax benefits you should explore. Here in Canada, a portion of your home utility bills are tax deductible if you are a permanent work-from-home employee. For those who have to commute, getting that hour or two back that would normally be spent sitting in a car can be priceless. That is time that can be better spent with family and doing the things you love.
I hope these tips help others. If you have other suggestions, please feel free to add a comment below or on Twitter.