sync-ing client with the server

Ammammata wrote:

VanguardLH:

So your user is in a domain that is setup for roaming profiles.
Configuring the host to NOT use a roaming profile when connecting to the
corporate domain means not having to download or save it over the
network.

since the user doesn't make any backup (his data are also on the server and
the server makes backup), if I disable the "roaming" profile I need to
configure a separate backup, i.e. to the NAS, that will run in background
or during lunchtime, or after work (switching off the computer at the end).

I have yet to see a corporate environment, even for small companies of
10 employees, that do not employ a backup strategy. That is, either the
workstation performs its own backup separately to a network storage
location or locally removable media or a client is installed on the
workstation that performs the backups when prompt by the server-side
backup program that controls when, who, and other factors of backing up
the workstations in the corporate network.

Relying on the roaming profile to do the backup neglects files stored
elsewhere, including system and application files. Say the user tweaks
MS Word away from its install-time settings. Most users do so after
using MS Word for a little while. Not all app config changes are stored
in files (under the profile's appPath folder). They may make registry
changes when installing or using the program Some changes may be in the
HKCU hive which is a .dat file stored under the user profile so changes
in that hive in the registry will get saved in the roaming profile.
Changes elsewhere, like to the HKLM hive, are not stored in the user
profile and many programs make registry changes in the non-user hive
(i.e., they are global or all-user registry changes). Another example
are programs that store their data under their own install folder. Not
recommended but it happens. Windows 7 started to protect the app
folders to discourage that behavior and force them to store in the user
profile's appdata folder. I don't know if there is a workaround to the
Win7+ protected folder behavior but suspect there might be. Typically
users are told to install the violative app somewhere other than under
C:\Program Files [x86] to get around the protected folder behavior.
Well, that alternative programs folder won't be in the user's profile so
it won't get "backed up" in the server's copy of the roaming profile. A
sysprep restore on that workstation and downloading the roaming profile
will not restore the user-modified config changes to the apps, or the
config changes to the OS, or any changes made elsewhere outside the
user's profile, or registry changes NOT within the HKCU hive. The
workstation cannot be restored properly if the roaming profile is the
only means for backup.

The roaming profile was never intended as a backup procedure. It is, as
per its name, intended to allow users to roam to other workstations
managed under the same PDC. It is a *roaming* profile, not a backup
profile. Misuse of just the roaming profile means restores will not be
what the customer expects for the workstation. That something works
doesn't mean that is the correct way. I can use a screwdriver as a
hammer, too, until the handle chips and the chip flies into and damages
my eye.

The user by choice or ignorance has decided to use their roaming profile
as their primary and possibly only means of backing up their data.
That's their choice to have a huge-sized profile. It is also their
choice to incur the long download time when they log into a domain to
have that huge roaming profile downloaded to their workstation (and any
workstation to which they roam that is under control of the same PDC).
If they don't like the consequences of their choice then they'll have to
make a different choice. Nothing you can do about someone that demands
they carry umpteen bags of luggage with all their wardrobe when they
drive to and from work instead of just doning the clothes they will wear
that day. It's their choice to lug around all that baggage.