Indietro
Over the last year and a half, we all went through the monumental disruption of having just about everyone work from remote locations. We strained VPN infrastructure and out of necessity split tunnels became the norm, not the exception. Even if it meant the users were a bit more exposed, you really had no choice, as Zoom/Webex/Teams meetings can eat up bandwidth like nobody’s business.
But now the users are starting to come back into the office, what’s the big deal? If everything worked just fine 18 months ago, this should be a walk in the park, no?
Well, maybe. Ah, the classic technologists’ answer: “It depends.” So, here are some things you may not have thought about regarding your network to consider as users are starting to trickle back into the office.
Have you made sure that every infrastructure device has been updated?
Firewalls, access points, IPS, IDS, proxies, and to a lesser degree, routers/switches require maintenance. And maintenance means changing controls and disruption of service. So get going now to make sure everything is updated and has been properly rebooted.
Did you make any changes to the network?
New or changed subnets? If you were thinking of changing routing protocols (EIGRP to BGP or OSPF for example) it was the perfect time to do it. Maybe you still have time to convert from legacy to modern routing protocol. But here’s a power tip: Before making changes to a remote router, make sure you save the current configuration and type in “reload in 30” to have the router reboot in 30 minutes to recover. It’s cheap insurance. Oh, and don’t forget to type “reload cancel” afterward too. I’m sure now you see why saving the existing configuration is *SO* important.
If you introduced new subnets or re-IP’ed existing ones, make sure you work with your proxy team to update the PAC file. At best, your users will be annoyed, but at worst your SaaS/Cloud apps won’t work. This is especially bad if your helpdesk app is SaaS-based. Recursive routing can be bad, but recursive workflow can really bite you.
Have you updated your Global Address Book and desktop Windows/Macs?
You might think you’re covered on this because every laptop is managed and in turn, they have all of the most recent updates, right? But what about all those desktop PCs and Macs back at the office that are being fired up for the first time in more than a year? Global address books can reach 100’s of MBs if you’re a large company, so imagine every desktop downloading a 100MB+ file all within the first hour of being booted up. Ask me how I know! And the PC updates? As we say in New York City, Fuggedaboutit! If you have WakeOn LAN PCs, now would be a good time to ask your helpdesk team to power those PCs on.
Finally, how will human behavior factor in?
Many of your users have (very) high-speed internet at home and they have gotten used to that speed for SaaS/Cloud and Internet in general. I’m sure your Internet connection is a shared service, so give your helpdesk a heads up that they may get a deluge of “the network is slow” emails and phone calls. With that in mind, do you have a good strategy to triage it? And here’s a surprising answer: Speed test apps ARE NOT YOUR ANSWER. Those apps are meant to stress the network to find the maximum available bandwidth but will do nothing to help identify users having a bad internet experience. Instead, find a way to stress test WITHIN your network. Ideally a website or even licensed speed test infrastructure that you run on-premises. Or at least make sure you have automated tests going through your proxies. This will help rule out the internal network as your problem. I like using Google and Disney as two extreme test cases—simple/light to a very content-heavy website. Finally, make sure you have a way of testing if the users are connected via hardlines or via Wifi. If you use Chrome, the debug log has a treasure trove of information that you can use.
If you’d like to hear more from me about what to consider before returning to the office, check out my episode of the Tech Bytes Podcast here!
Leggi il blog