Ready2Blob/.planning/research/FEATURES.md

Feature Landscape

Domain: rclone configuration wizard / enterprise deployment helper Project: Ready2Blob Researched: 2026-03-26 Confidence note: External research tools (WebSearch, WebFetch, Bash) were unavailable in this session. All findings are from training data (knowledge cutoff August 2025). Confidence levels are assigned conservatively. Recommend validating against live rclone docs and community forums before finalizing.

---

Table Stakes

Features IT admins expect. Missing any of these means the tool gets discarded immediately.

Feature	Why Expected	Complexity	Notes
Multi-step backend selection wizard	rclone has 50+ backends; admins need guided selection, not raw docs	Medium	First screen should show backends sorted by popularity: Azure Blob, S3, OneDrive, SFTP, then others
Per-backend field forms with labels	Each backend has different required fields (account name vs access key vs OAuth token); forms must match	Medium	Source of truth is rclone's own rclone config flow; replicate those fields exactly
Valid rclone.conf output	The generated file must be parseable by rclone with no errors	Low	INI-like format: [remote-name], type = azureblob, then key=value pairs. Pure string generation
Remote name customization	Admins name remotes to match org conventions (e.g., corp-backup, client-files)	Low	Single text input, validated to allow only rclone-safe characters (alphanumeric, dash, underscore)
Intune PowerShell deployment script	Intune Win32 app or PS script deployment is the dominant MDM workflow for Windows	High	Must handle: detection script, install script, optional rclone.exe download, config placement at correct path
RMM deployment script	NinjaRMM, Datto RMM, ConnectWise Automate, Syncro — MSP-dominant tools	High	Single PS script that downloads rclone if needed and drops config; simpler than Intune (no detection logic needed)
Optional rclone install inclusion	Some orgs already have rclone in their baseline image; others don't	Medium	Checkbox: "Include rclone installation". If checked, script downloads from rclone.org/downloads or GitHub releases
Security warning before download	Credentials are in plain text in generated files — legal/compliance exposure if admin doesn't understand	Low	Modal or banner: "This file contains your storage credentials in plain text. Store and transmit securely." Must be impossible to miss
Download individual output files	Admin may only need the .conf, or only the script, depending on their environment	Low	Separate download buttons for each generated artifact
No data sent to server	IT security teams will ask "where do my credentials go?" — answer must be "nowhere, browser only"	Low	Static site + client-side generation. Prominently state this in UI

Differentiators

Features that set Ready2Blob apart from "just read the rclone docs" or copy-pasting PS scripts from Reddit.

Feature	Value Proposition	Complexity	Notes
Intune-specific detection script generation	Intune Win32 apps require a separate detection script (exit 0 = installed); most admins copy-paste wrong ones	Medium	Detect by checking rclone.exe presence at install path AND config file presence. Both must exist
Intune packaging hints / IntuneWinAppUtil guidance	After generating scripts, show admin the exact IntuneWinAppUtil command to wrap the installer	Low	Static text block, not dynamic generation — but reduces a common stumbling point
RMM-specific script variants	NinjaRMM, Datto, and ConnectWise have slightly different execution contexts (SYSTEM vs user, working dir)	High	Start with a generic "SYSTEM context" PS script that works across RMMs; add named variants later
Rclone version pinning	MSP environments require reproducible deployments; "latest" is not acceptable for production	Low	Text input: "Pin to rclone version" (e.g., v1.68.2). Defaults to latest stable. Affects download URL in script
Config placement path options	Config can go to %APPDATA%\rclone\rclone.conf (user) or a machine-wide path. Intune SYSTEM context needs machine-wide	Medium	Dropdown: User profile path vs machine-wide path (C:\ProgramData\rclone\). Explain implications of each
Multiple remotes in one config	A single rclone.conf can contain multiple named remotes; some orgs need 2-3 backends on same endpoint	High	Allow "Add another remote" in wizard. Generates a single .conf with multiple sections
Live config preview	Admin sees the exact text of generated files before downloading — builds trust, catches errors	Low	Syntax-highlighted read-only textarea. Updates in real time as form fields change
Copy-to-clipboard for each output	Some RMM tools have a "run script" field — paste directly without downloading a file	Low	Copy button beside each output block
Field-level validation with rclone-specific rules	Azure Blob storage account names are 3-24 lowercase alphanumeric chars — catch this before the admin deploys a broken config	Medium	Per-field regex/rule validation. Reduces "why doesn't rclone connect?" support tickets
Explanatory tooltips on sensitive fields	"What is an SAS token vs an Access Key?" — admins often don't know which credential type to use	Low	Tooltip or inline help text per field. Reduces abandonment from confusion
Backend popularity ordering	Show Azure Blob, S3, OneDrive, SFTP, GCS at top — don't bury them alphabetically	Low	Simple UX decision with high impact on time-to-task-complete

Anti-Features

Features to explicitly NOT build in v1 — scope creep killers.

Anti-Feature	Why Avoid	What to Do Instead
Test connection / validate credentials	Requires a backend proxy (CORS blocks direct cloud API calls from browser); breaks the "no server" constraint entirely	Show a callout: "Run rclone lsd remote-name: on any Windows PC after deploying to verify connectivity"
Save / load configurations	Requires either a backend (no-server constraint violated) or localStorage (credentials in browser storage = security incident)	Tell user to save the downloaded .conf file. That IS their save format
User accounts / authentication	No backend = no accounts. Would require a complete architecture rethink	Out of scope permanently for v1. Re-evaluate only if architecture changes
rclone mount / sync scheduling	UI for configuring rclone mount or scheduled sync jobs adds a second problem domain (task scheduler, Windows service) on top of the first	Separate product decision. Ready2Blob focuses solely on getting rclone configured and deployed
Auto-push to Intune via Graph API	Would require Azure AD app registration, OAuth flow, Graph API integration — massive scope increase	Generate files the admin uploads manually. Graph API is a v2+ consideration
Multi-OS support (macOS, Linux)	Scripts are PowerShell for Windows. macOS/Linux have different path conventions, shell scripts, MDM tools	Out of scope for v1. State clearly in UI: "Windows endpoints only"
rclone version auto-update logic	Keeping rclone up to date on endpoints is a separate lifecycle management problem	Point admin to rclone's own update mechanism or their RMM's patch management
Visual diff of old vs new config	Requires knowing what's already deployed — impossible without a backend	Not viable without persistence layer
Encryption of config credentials	rclone supports rclone config password-encrypted configs but requires interactive unlock on each use, incompatible with unattended deployment	Document the limitation; recommend Azure Key Vault or Intune-native secrets for sensitive deployments

---

Feature Dependencies

Backend selection
  → Per-backend form fields (fields depend on selected backend type)
      → Remote name input
          → rclone.conf generation (depends on: backend type, all field values, remote name)
              → Intune script generation (depends on: config content, install option, config path choice)
              → RMM script generation (depends on: config content, install option, config path choice)
                  → Version pin input (affects download URL inside both scripts)
                  → Config path option (affects file placement command inside both scripts)

Live config preview → rclone.conf generation (real-time rendering of same output)
Download buttons → all generation outputs (nothing to download until form is valid)
Security warning → download buttons (warning must be acknowledged before download is enabled)

---

MVP Recommendation

Prioritize in this order:

1. Backend selection + per-backend forms (Azure Blob, S3, OneDrive, SFTP as initial set — covers 80% of use cases)
2. rclone.conf generation with live preview
3. Intune PowerShell script generation (primary target audience pain point)
4. RMM PowerShell script generation
5. Security warning gate before download
6. Optional rclone install toggle
7. Config path selector (user vs machine-wide)

Defer to post-MVP:

• Multiple remotes in one config: adds wizard UX complexity; single remote covers the majority of deployments
• RMM-named variants (NinjaRMM-specific, Datto-specific): start with generic SYSTEM-context PS script
• Intune IntuneWinAppUtil packaging hints: valuable but can be a static docs page
• Version pinning: default to latest stable with a text field; low-effort add
• Field-level validation beyond basic required-field checks: adds significant per-backend maintenance burden

---

Backend Coverage Priority

Based on enterprise Windows deployment prevalence (HIGH confidence from domain knowledge):

Tier	Backends	Rationale
Tier 1 — Must ship in v1	Azure Blob Storage, Amazon S3, Microsoft OneDrive	Dominant in enterprise; covers ~70% of use cases. "Ready2Blob" brand implies Azure first
Tier 2 — Ship in v1 if feasible	SFTP, Google Cloud Storage, Backblaze B2	Common in MSP environments and SMB
Tier 3 — Post-v1	Google Drive, Dropbox, SharePoint, S3-compatible (Wasabi, MinIO, etc.)	Consumer-origin or niche; lower enterprise priority
Tier 4 — Document only	All remaining rclone backends (50+)	Too many to form-ify in v1; link to rclone docs

Note on S3-compatible backends: Amazon S3 forms should include an "endpoint override" field so the same form handles Wasabi, MinIO, Cloudflare R2, etc. This is how rclone handles them natively — provider + optional endpoint. One form, many backends. (MEDIUM confidence — verify against rclone S3 docs)

---

IT Admin Expectations (Contextual)

These are workflow expectations rather than discrete features, but they inform every feature decision:

• Scripts must run as SYSTEM — Intune and most RMMs execute scripts as SYSTEM, not as the logged-in user. Config path must be machine-wide, not %APPDATA%. This is the single most common deployment failure mode.
• Scripts must be idempotent — Running the install script twice must not break anything. Check-then-act pattern: if rclone.exe already exists and config already exists, exit 0.
• Scripts must have exit codes — Intune uses exit codes to determine success/failure of a deployment. Script must exit 0 on success, non-zero on failure.
• Detection scripts must be separate from install scripts — Intune Win32 app model requires them to be distinct. Many generated scripts online conflate them.
• No interactive prompts — Scripts run silently. Any Read-Host, Write-Host expecting input, or UAC prompt breaks unattended deployment.
• 64-bit PowerShell — Intune on 64-bit Windows sometimes executes PS in 32-bit mode. rclone.exe path may differ. Scripts should force 64-bit context or be path-aware.

(Confidence: HIGH for SYSTEM context and exit codes — verified by common Intune troubleshooting canon. MEDIUM for 32/64-bit PS caveat — common but less universally documented.)

---

Sources

• rclone official documentation (rclone.org) — not fetched in this session due to tool restrictions; referenced from training data (knowledge cutoff August 2025)
• Microsoft Intune Win32 app deployment model — training data (HIGH confidence on SYSTEM context, exit codes, detection script requirements)
• RMM deployment patterns (NinjaRMM, Datto, ConnectWise) — training data (MEDIUM confidence)
• rclone.conf INI format specification — training data (HIGH confidence; format is stable and well-documented)

Validation recommended before roadmap finalization:

• Confirm current rclone backend list and required fields per backend at rclone.org/overview
• Confirm Intune Win32 app detection script requirements in current Microsoft docs
• Check if rclone has changed S3-compatible provider+endpoint pattern in recent releases