Faronics Cloud is straightforward to set up and use - but that doesn't mean there aren't ways to get it wrong. New users often make similar mistakes, usually from rushing deployment, misunderstanding how the tools work, or carrying over assumptions from other systems.
The good news: these mistakes are predictable and avoidable. Learning from others' experiences means you can deploy confidently and get the benefits without the frustration of troubleshooting self-inflicted problems.
This guide covers the most common mistakes during initial setup and policy configuration, plus practical advice for avoiding each one.
Setup Mistakes
These mistakes happen during initial deployment and can cause problems that persist throughout your use of Faronics Cloud:
Mistake 1: Freezing before the baseline is ready
What happens: You install Deep Freeze and freeze the system before everything is properly configured. Missing software, wrong settings, pending updates - all become permanently locked in.
Why it's a problem: Every reboot restores this incomplete baseline. You end up thawing constantly to fix things, or worse, users struggle with a system that's missing what they need.
How to avoid it: Create a deployment checklist. Before freezing, verify: all required software installed and configured, Windows fully updated, user profiles set up correctly, printers and peripherals configured, browser bookmarks and extensions in place, any customisations applied. Test the machine as a user would. Only freeze when everything works.
Mistake 2: Deploying to all devices at once
What happens: Eager to see results, you deploy Faronics Cloud to your entire fleet simultaneously. If something's wrong with the configuration, every device has the problem.
Why it's a problem: Issues that would be minor on a pilot group become major incidents when they affect hundreds of devices. You're troubleshooting under pressure with upset users everywhere.
How to avoid it: Always start with a pilot group - perhaps one lab or 10-20 representative devices. Run for at least a week, ideally two. Gather feedback, identify issues, refine your approach. Only then expand to the broader fleet.
Mistake 3: Forgetting to configure ThawSpace
What happens: Deep Freeze is installed without configuring ThawSpace (the protected area for data that should persist). Users save work, reboot, and it's gone.
Why it's a problem: Data loss creates immediate user frustration and erodes trust in the system. "Deep Freeze deleted my files" becomes the narrative, even though that's exactly what it's designed to do.
How to avoid it: Before deployment, decide where users should save persistent data - network drives, cloud storage, or a configured ThawSpace partition. Communicate this clearly. Configure folder redirection if appropriate. Train users on where to save before rolling out Deep Freeze.
Mistake 4: Not testing the agent installation process
What happens: You create a deployment package but don't thoroughly test it. When deployed at scale, some machines fail to install, install incorrectly, or don't check in.
Why it's a problem: Partial deployment means some devices are protected and some aren't. Tracking down failures across a large fleet is tedious.
How to avoid it: Test your installation process on several machines with different configurations - different hardware, different software loads, different Windows versions if applicable. Verify each test machine appears in the console and responds to commands before proceeding.
Mistake 5: Ignoring network requirements
What happens: Faronics Cloud requires communication with cloud servers. Firewalls, proxies, or network policies block this traffic. Devices install but can't check in or receive policies.
Why it's a problem: Devices appear offline in the console even though they're on the network. Policy changes don't propagate. Remote management doesn't work. You've installed software that can't do its job.
How to avoid it: Review Faronics documentation for required URLs and ports before deployment. Work with your network team to ensure these are accessible. Test connectivity from a pilot device before broad deployment.
Mistake 6: Not documenting the baseline
What happens: You carefully configure a baseline, freeze it, then six months later can't remember exactly what's in it or how it was configured.
Why it's a problem: When you need to update the baseline or troubleshoot issues, you're guessing at what the original configuration was. Replication becomes difficult if you need to set up new machines.
How to avoid it: Document everything before freezing: installed software and versions, Windows update status, configuration changes made, user accounts created. Keep this documentation updated whenever you modify the baseline.
Policy Mistakes
These mistakes relate to how you configure and apply policies across your device groups:
Mistake 7: Making policies too restrictive too quickly
What happens: Excited about security, you lock everything down immediately. WINSelect blocks access to everything. Anti-Executable allows almost nothing. Users can't do their work.
Why it's a problem: User revolt. Complaints flood in. You spend days responding to "I can't access..." tickets. Pressure mounts to remove the restrictions entirely, losing the security benefits.
How to avoid it: Start permissive, tighten gradually. Deploy with minimal restrictions first. Monitor what users actually need. Then incrementally add restrictions, testing each change. It's easier to add restrictions than to walk back overly aggressive ones.
Mistake 8: Using the same policy for different use cases
What happens: You create one policy and apply it everywhere - computer labs, library computers, staff workstations, reception kiosks. But these have different needs.
Why it's a problem: Settings appropriate for a public kiosk are too restrictive for a staff workstation. Settings appropriate for staff are too permissive for a student lab. You either over-restrict some users or under-protect some devices.
How to avoid it: Create device groups based on use case, not just location. Develop appropriate policies for each: public access, student use, staff use, exam rooms, etc. Apply the right policy to the right group.
Mistake 9: Scheduling maintenance at the wrong time
What happens: You schedule maintenance windows without considering when devices are actually available. Updates run during classes. Or machines are off when maintenance is supposed to occur.
Why it's a problem: Maintenance during use hours disrupts users. Maintenance when devices are off doesn't happen at all. Either way, updates don't get applied reliably.
How to avoid it: Map out when each device group is used and when it's available. Schedule maintenance for early morning, evening, or weekends - times when devices are on but not in use. Consider different schedules for different groups.
Mistake 10: Forgetting to build an Anti-Executable whitelist
What happens: Anti-Executable is enabled without first creating a comprehensive whitelist. Legitimate applications are blocked. Users can't run the software they need.
Why it's a problem: Immediate disruption. Every blocked application requires investigation and whitelisting. Users lose confidence in the system.
How to avoid it: Before enabling Anti-Executable, use its scanning feature to inventory existing executables and create a baseline whitelist. Run in audit mode first if available, to identify what would be blocked without actually blocking it. Only enable enforcement once you're confident the whitelist is complete.
Mistake 11: Not planning for legitimate software additions
What happens: The baseline is frozen, Anti-Executable is locked down - and then a teacher needs new software installed, or a critical update requires adding executables.
Why it's a problem: Without a process, every software request becomes an emergency. You're constantly thawing, installing, updating whitelists, refreezing - exactly the manual work you were trying to avoid.
How to avoid it: Establish a software request process before deployment. Define how requests are submitted, who approves them, and how changes are rolled out. Schedule periodic baseline update windows - perhaps monthly or at half-term - for non-urgent additions.
Mistake 12: Ignoring policy inheritance
What happens: You create a complex hierarchy of groups and policies without understanding how settings inherit from parent groups. Child groups get unexpected configurations.
Why it's a problem: Devices don't behave as expected. Troubleshooting becomes confusing because the active settings come from inherited policies you forgot about.
How to avoid it: Keep your group structure simple initially. Understand exactly how policy inheritance works before creating complex hierarchies. Document which settings come from which level. Verify effective policies on test devices before broad deployment.
How to Avoid These Mistakes: A Practical Approach
Beyond avoiding individual mistakes, here's a general approach that prevents most problems:
Plan before you deploy
Resist the urge to start installing immediately. Spend time planning:
• What device groups do you need?
• What policies apply to each group?
• What should be in each baseline?
• Where will users save persistent data?
• When should maintenance occur?
• What's your process for software requests?
An hour of planning prevents days of troubleshooting.
Pilot everything
Never deploy changes to your entire fleet without testing first:
• New installations: pilot group first
• Policy changes: test group first
• Baseline updates: one lab first
• New restrictions: small group first
Problems on 10 devices are manageable. Problems on 200 devices are crises.
Document as you go
Maintain documentation from day one:
• Baseline configurations: what's installed, how it's configured
• Policy assignments: which policies apply to which groups
• Change history: what changed, when, why
• Known issues: problems you've encountered and solutions
Future you will thank present you for this documentation.
Communicate with users
Many problems come from user surprise, not technical issues:
• Before deployment: explain what's changing and why
• Data handling: clearly explain where to save files that should persist
• Restrictions: explain what's restricted and why
• Support process: explain how to request changes or report issues
Users who understand the system work with it rather than against it.
Start simple, add complexity gradually
You don't need to implement everything immediately:
• Week 1-2: Deploy Deep Freeze with minimal restrictions
• Week 3-4: Add WINSelect restrictions incrementally
• Month 2: Introduce Anti-Executable with thorough whitelist
• Ongoing: Refine based on experience
Gradual rollout lets you learn and adjust without overwhelming users or yourself.
Frequently Asked Questions
What if I've already made some of these mistakes?
Most are recoverable. You can update baselines, adjust policies, reconfigure settings. It takes time, but it's not permanent damage. The key is identifying the specific issue and addressing it systematically rather than making hasty additional changes.
How long should a pilot run before broader deployment?
At least one week for basic testing, two weeks ideally. You want to experience a full cycle of typical use, including any scheduled maintenance. Longer pilots for more significant changes.
Should I involve users in planning?
Yes, especially for understanding what software they need and what restrictions would prevent them working. Key users or department representatives can provide valuable input. They'll also become advocates if they feel heard.
What's the single most important thing to get right?
The baseline. Everything else can be adjusted through policy changes, but the frozen baseline is foundational. Take your time getting it right before freezing.
The Bottom Line: Learn from Others' Mistakes
Every mistake on this list has been made by someone - probably many times. The patterns are predictable: rushing deployment, starting too restrictive, not planning for data persistence, skipping pilots, neglecting documentation.
The common thread: taking time upfront prevents problems later. Plan before deploying. Pilot before expanding. Document as you go. Communicate with users. Start simple and add complexity gradually.
Faronics Cloud is designed to make your life easier. Following these guidelines ensures it actually does.
Ready to Get Started the Right Way?
Try Faronics Cloud free for 30 days. Use the trial period to pilot properly before committing.
