Proxmox Backup to NAS: NFS vs SMB Setup and Restore Checklist

Preparation date: September 17, 2026. Scope: This is a documentation-based implementation and verification guide, not a claim about a completed customer incident. It covers ordinary Proxmox VE VZDump backups written to NAS storage. A Proxmox Backup Server datastore is a different architecture and is called out separately. The short answer is: choose NFS when Proxmox is the main consumer and your NAS can restrict the export to the Proxmox node addresses. Choose SMB/CIFS when the same share must also fit a Windows-oriented operating model or your NAS administration is already built around named users and SMB permissions. The protocol choice matters, but the restore test matters more. A green backup task proves that an archive was written; it does not prove that you can recover a VM on replacement storage. Proxmox backup to NAS verification flow A Proxmox node writes a VZDump backup over NFS or SMB to a NAS, then a separate restore test validates recovery. ...
Post a Comment

Slow Windows Logon in VDI: Separate Group Policy Time from Profile and Script Delays

Documentation-based investigation guide. Revised September 12, 2026. This is not a measured incident report. The earlier generic registry-debug recipe has been removed in favor of scoped evidence collection and restoration of diagnostic settings.

A slow Windows logon is not necessarily a slow Group Policy application. First separate the interval before credentials are accepted, policy processing, profile preparation, desktop availability, and application startup. Otherwise a policy change may target the wrong portion of the wait.

Record a useful comparison

Note the user, desktop type, image build, OU, site, chosen domain controller, profile technology, and whether the profile is new or reused. Protect those identifiers in shared evidence. Compare first and subsequent logons, but recognize that caches and profile creation change between them; a faster second logon does not by itself identify a slow policy.

Separate effective policy from elapsed time

Microsoft recommends using the GroupPolicy Operational log and correlating the relevant processing activity when troubleshooting application. A policy-results report helps establish what applied. Do not treat a list of applied policies as a complete timing trace of every logon component.

  1. Record the start and end of the user-visible delay and the timezone.
  2. Export the corresponding GroupPolicy Operational events and policy results for that user and computer.
  3. Match the relevant activity and extension events to the observed interval; do not mix background refresh events with the logon under investigation.
  4. If policy activity does not account for the delay, investigate profile, script, storage, DNS, or application startup evidence in that interval instead.

A delayed script is not always a frozen logon

Microsoft documents a logon-script delay behavior for specified Windows versions and settings. A script starting late after the desktop is usable is different from the user waiting for the desktop. Check the installed version and effective policy before changing the delay setting; removing an intentional delay can move work into a busier part of startup.

Make a narrow pilot change

Only after timing identifies a suspect extension or script should its owner propose a change. Preserve the GPO configuration, links, filters, and intended scope. Use an approved test group or pilot OU without accidentally removing security controls. Change one variable and repeat comparable logons, recording both usability and expected policy behavior.

If more detailed tracing is required, follow Microsoft's applicable diagnostic procedure with an owner-approved capture window. Record the original logging settings, protect collected data, and restore temporary tracing afterward. Do not leave verbose logging indefinitely or edit registry values copied from an unrelated Windows release.

When the evidence belongs elsewhere

Escalate with a short timeline: user-visible delay, correlated activity, slow or failed component, comparison result, and unchanged variables. If the policy interval is normal but the profile interval is slow, hand over the evidence to the profile/storage owner instead of disabling more GPOs. A closed incident needs repeated improvement and correct policy application, not just one faster login.

References

Related troubleshooting guides

Comments

Post a Comment

Popular posts from this blog

Horizon vdpConnect_Failure: Connection-Stage Triage Before Reinstalling

vdpConnect_Failure is a starting symptom, not a root-cause diagnosis. Before reinstalling Horizon Agent or opening firewall ports, establish whether the failure occurs during authentication, desktop launch, or an established session. This documentation-based triage guide does not report a reproduced incident or a universal fix. Corrected September 12, 2026: The earlier guide suggested restarting the Windows RPC service and treated a local netstat listing as a test for blocked ports. Those instructions have been removed. A socket listing does not demonstrate end-to-end reachability. Classify the failure before making changes Observation First evidence to collect Avoid assuming Authentication never completes Exact login error, identity provider or broker event, timestamp That the display protocol is the failing component. Desktop selection succeeds, launch fails Assigned desktop, chosen protocol, Client/Agent and gateway logs That a successful HTTPS login proves the session path ...
Read more

Horizon Agent Unreachable: Registration and Desktop-Health Triage

Start an “Agent Unreachable” investigation by separating desktop health, Agent registration, and session traffic. Do not begin with a pool rebuild. This documentation-based triage guide helps decide which team should act and what evidence to preserve. Correction, September 12, 2026: The earlier guide mixed display ports with Agent communication, tested Blast against the Connection Server, and offered generic service restarts and image rebuilds. Those instructions have been replaced with path-specific investigation. First-response decision table Check Evidence Investigation owner Is the guest responsive? Approved console access, OS health, resource and disk observations Desktop/virtualization team if the OS is unavailable. Is this one desktop or a whole image family? Affected pool, image revision, Agent version, start time Image owner if failures align with a deployment. Does registration fail? Agent and Connection Server events for the same desktop and time Horizon team, then netw...
Read more

Horizon Protocol Error: Trace the Display-Session Handoff

A desktop can authenticate successfully and still fail to establish its display session. This guide investigates that handoff. Use it after identifying the actual console/client error, not as a claim that every “Protocol Error” means a firewall failure. Correction, September 12, 2026: The previous version combined a general checklist with an unverified incident narrative, conflated gateway and desktop port directions, and recommended blanket endpoint-security exclusions. Those instructions have been removed. This is a documentation-based diagnostic plan. Draw the attempted connection Record the selected protocol, assigned desktop, Client and Agent versions, gateway route, and attempt time. Distinguish a direct internal connection from an external UAG connection or a Connection Server tunnel. Use Omnissa's connection guide to identify where the failed handoff occurs. Stage Question Useful comparison Authentication Did the user receive desktop entitlement? Failed login versus ...
Read more