Export (0) Print
Expand All

IntelliMirror Tips and Tricks

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Jason Rush

Technical Writer, Microsoft Corporation

March 1, 2000

On This Page

Introduction
IntelliMirror Definition
Group Policy Components of IntelliMirror
Group Policy Tips and Tricks
Software Installation and Maintenance Tips and Tricks
Folder Redirection Tips and Tricks
Offline Folders Tips and Tricks
User Profiles and Roaming User Profiles Tips and Tricks
Remote Installation Services Tips and Tricks
Other Issues and Considerations

Introduction

Many IT professionals start by experimenting with the actual product before having a chance to review the materials. Use these tips and tricks to help you make the best use of Microsoft IntelliMirror® features. But because each environment is unique, use the links provided throughout this article to find further information.

The majority of the tips and tricks we present apply to existing managed environments, but early planning of your environment is never a mistake. Here's what I recommend:

  • Plan your deployment of Microsoft Windows® 2000 Active Directory® directory service

  • Determine what client-side features are important to your users

  • Read the documentation

In this article, I provide the following information:

  • How best to use these IntelliMirror technologies alone and in conjunction with related technologies in an integrated fashion

  • Common missteps, subtle issues, and how to avoid them

  • Where to find more information

These tips and tricks were culled during the deployment process of Microsoft Windows® 2000 at Microsoft in the Microsoft Windows NT® Development domain, ITG, and with many of our JDP partners. These may or may not apply to your organization, and we always recommend that you test in the lab and perform a pilot of all these items before deploying to your entire organization.

IntelliMirror Definition

Windows 2000 Server includes powerful new features to simplify computer system administration. IntelliMirror is a designation for Windows 2000 Change and Configuration Management features enabling you to manage user data and settings, and to install and maintain software throughout your organization.

IntelliMirror enables an administrator to set policy definitions once and be confident that the policy will be applied without further administrative intervention.

At the core of IntelliMirror are three categories of administrative responsibility:

  • User data management

  • Software installation and maintenance

  • User settings management

IntelliMirror features can be used separately or together, depending on the business or organizational requirements.

IntelliMirror Documentation

As an administrator you should consult the following documentation before, during, and after you deploy Windows 2000:

  • Windows 2000 Server online help. This is indexed, searchable, compiled HTML help in the form of .chm files. Click Start, Help to see all the help. Click Help from within an MMC console to get help for the tool you are using.

  • Windows 2000 Server Resource Kit. This includes indexed, searchable HTML help on CD-ROM and also printed books. Of particular interest is GP.chm, which provides details about numerous settings that you can configure using Group Policy. The Resource Kit also has a section devoted to Remote Installation Services. The Deployment Planning Guide is online at http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/w2rkbook/dpg.asp.

  • The Microsoft Windows website at http://www.microsoft.com/windows/default.mspx has numerous useful links.

  • The Microsoft Knowledge Base is a searchable database of the latest technical information on Microsoft products including Windows 2000. Several Knowledge Base articles are mentioned here, and keyword searches will lead you to many more. See http://support.microsoft.com/default.aspx?scid=fh;EN-US;KBINFO.

Well-informed use of the IntelliMirror features of Windows 2000 is essential because the tools can have wide scope. Mistakes might inconvenience a broad swath of users. Confirm the behavior you anticipate in test labs if you have doubts. Use this as a quick reference when you're planning and deploying this feature set.

Group Policy Components of IntelliMirror

IntelliMirror includes Group Policy, whose components are summarized in the following table.

Component

Use

Administrative Templates

Registry based policy, known as System Policy in Windows NT 4.0

Security Settings

Security settings for domains, computers, and users

Software Installation

Assign or publish applications

Internet Explorer Maintenance

Administer Internet Explorer after deployment

Scripts

User logon/logoff and computer startup/shutdown

Folder Redirection

The ability to redirect folders and files to the network

IntelliMirror, particularly Group Policy, is closely tied to Active Directory. Group Policy objects are linked to sites, domains, and organizational units in Active Directory, and Group Policy is usually opened from one of the Active Directory MMC consoles. Furthermore, every Active Directory container and object is secured by Access Control Lists (ACLs). Active Directory and security are large topics in their own right, so you should not only follow the IntelliMirror pointers provided here, you should also familiarize yourself with Active Directory and the Windows 2000 security model.

Group Policy Tips and Tricks

Group Policy is the primary Windows 2000 tool for configuring administrative policy on users and computers.

  1. Use security settings to enable the right to log on locally to a domain controller

    This has more to do with Active Directory and Security than with IntelliMirror, but nearly everyone puzzles over this at an early stage. See the knowledge base articles

    • 186529 Local Policy Does Not Permit You to Log On Interactively<http://support.microsoft.com/default.aspx?scid=KB;en-us;186529&sd=tech>

    • 234237 Assign "Log On locally" Rights to Windows 2000 Domain Controller<http://support.microsoft.com/default.aspx?scid=KB;en-us;234237&sd=tech>

  2. Use Group Policy in preference to Windows NT 4.0 System Policy

    System Policy is undesirably persistent from a Windows 2000 perspective. Group Policy is cleaned up and refreshed whenever policy changes. See Windows NT 4.0 system policies in the online help for details.

  3. Disable unused parts of a Group Policy object

    If you notice that under the User Configuration or Computer Configuration node of the console, a Group Policy object only has settings that are Not Configured, then you can avoid processing those settings by disabling the node. This expedites startup and the logon session for those users and computers subject to the Group Policy object.

    Disabling both parts of a Group Policy object makes it behave as if it is not linked to any site, domain, or organizational unit, even though the links still exist.

  4. Use the Block Policy Inheritance and No Override features sparingly

    Routine use of these features makes it difficult to troubleshoot policy.

  5. Minimize the number of Group Policy objects associated with users in domains or organizational units

    The more Group Policy objects are applied to a user, the longer it takes to log on.

  6. Filter policy based on security group membership

    Keep in mind that a Group Policy object will not apply to a user if the Read or Apply Group Policy access control entries (ACEs) are not set to Allow on security groups of which the user is a member. This is the mechanism by which policy can be prevented from applying to users (or computers) who would otherwise be subject to it either by links or by inheritance. It is a good, efficient mechanism, and the administrator can greatly expedite the logon and startup experiences of the users in his or her organization by exploiting it fully.

  7. Override user-based Group Policy with computer-based Group Policy only when necessary

    Do this only if you need the desktop configuration to be the same regardless of which user logs on.

  8. Avoid cross-domain Group Policy object assignments

    The processing of Group Policy objects slows the logon session and startup if Group Policy is obtained from another domain.

  9. Don't confuse policy and security

    Since IPSEC policy settings are set late in the processing of Group Policy. The data Group Policy sends across the network is not and cannot be encrypted.

  10. Don't refresh Group Policy too often if you are using a laptop computer

    Each refresh resets the hibernate timer, so too short an interval causes the computer never to hibernate. Laptop computers need to be frugal with power consumption.

  11. Use Loopback only in pure Windows 2000 environments

    Loopback is a setting for certain tightly managed environments like kiosks. The client computer must run Windows 2000 Server or Windows 2000 Professional. The computer account and the user account must both be handled by Windows 2000 domain controllers.

Software Installation and Maintenance Tips and Tricks

Use the Software Installation extension to Group Policy to assign or publish applications to those who need them. Usually these are in the form of Windows Installer files, which are characterized by the .msi extension.

  1. Specify application categories for your organization

    Using categories makes it easier for users to find an application in Add/Remove Programs in Control Panel. For example, you could define categories such as Sales Applications, Accounting Applications, and so on. For more information, see To specify categories for applications in the online help.

  2. Make sure Windows Installer packages are correctly transformed before they are published or assigned

    You cannot customize software deployments after they have been deployed. Transforms, or .mst files, are customizations applied to Windows Installer packages. Remember that transforms are applied to packages at the time of initial assignment or publication. A transform is applied at the time of assignment or publication, not at the time of installation. In practical terms, this means that you should make sure the Modifications tab of the package properties dialog box is set up as you intend before you click OK. If you neglect to do this, and assign or publish a package before you have completely configured it by adding the transform, then you can either remove the software and republish, or reassign it or upgrade the software with a completely transformed version. For procedures on how to do this, see To remove a managed application and To upgrade a managed application in the online help.

  3. Assign or publish a given application to either users or computers, but not both

    A Windows Installer package should be assigned or published no more than once in the same Group Policy object. For example, if you assign Microsoft Office to the computers affected by a Group Policy object, then do not also assign or publish it to users who will log on to the affected machines.

  4. Take advantage of Windows Installer authoring tools

    Developers familiar with the files, registry entries, and other requirements for an application to work properly can author native Windows Installer packages using tools available from various software vendors.

  5. Repackage existing software

    You can use commercially available tools to create Windows Installer packages for software that does not include natively authored .msi files. These work by comparing a computer's state before and after installation. For best results, repackage on a clean install of Windows 2000.

  6. Use Dfs for software distribution points

    Windows 2000 Distributed File System (Dfs) is helpful in managing the software distribution points (the network shares from which users install their managed software). Dfs enables you to construct a path to source files that remains constant regardless of the physical location of the source servers. This is transparent to users and it means that the servers can be changed, managed, or upgraded without adversely affecting users. Load balancing also improves and optimizes the installation experience for users.

  7. Be careful using Software Installation and SMS together.

    Don't deploy the same application with both Software Installation and SMS. You can use SMS and Software Installation together as long as you deploy different sets of applications for a given user with each of them.

  8. Assign or publish at a high level in the Active Directory hierarchy

    Because Group Policy settings apply by default to child Active Directory containers, it is efficient to assign or publish by linking a Group Policy object to a parent organizational unit or domain. Use security descriptors (access control entries or ACEs) on the Group Policy object for finer control over who receives the software. For more information, see Using security groups to filter Group Policy in the online help.

  9. Make sure permissions are set properly on the software distribution point

    Authenticated Users need the Read and Apply Group Policy ACEs to be able to install from the software distribution point. Administrators need Full Control to manage software.

  10. Save time if deploying multiple applications from the same distribution point

    In the Group Policy console, right-click Software Installation and on the context menu click Properties. You can find this in the Group Policy console under <Group_Policy_object_name>/Software Settings/Computer Configuration (or User Configuration)/Software Installation.

    This spares administrative keystrokes when assigning or publishing a large number of packages with similar properties in a single Group Policy object—for example, when all the software is published and it all comes from the same software distribution point. Compare this with the following tip.

  11. Use Windows Installer package properties for fine control

    Proceed to the Software Installation node as described previously, but right-click the package in the details pane and click Properties. Use this for assigning or publishing a single package.

  12. Deploy legacy software using .zap files if you cannot repackage it to use .msi.

    Windows Installer (.msi) files are the standard file type for assignment and publication of software, but if you need to use .zap files, see the Knowledge Base article 231747 How to publish non-MSI programs with .zap files<http://support.microsoft.com/default.aspx?scid=KB;en-us;231747&sd=tech>.

  13. Note correct .zap file syntax

    The path and name of the EXE file always needs to have quotation marks around it. If there are no command line arguments, it needs to have double quotation marks. For example, the following are all correct:

    Absolute path:

    SetupCommand=""\\server\share\long folder\setup.exe""
     SetupCommand="\\server\share\long folder\setup.exe" /argument
    

    Relative path:

    SetupCommand=""setup.exe""
     SetupCommand="setup.exe" /argument
    
  14. Don't set disk quotas too low

    If a user's disk quotas are set too low, software installation may fail. Make sure enough disk space is allocated not only for the installed applications and user data, but also for temporary files created during installation. Files needed for the installation may be manipulated in the user's context, so it is important that the user has sufficient disk space in his or her quota.

  15. Changing from unmanaged to managed

    If the administrator wants to avoid the situation of having an unmanaged installation of the application on the client computer, the best approach is to use the advanced option Remove Previous Installs of this product, if the product was not installed using Group Policy-based installation. This option is located on the advanced deployment option for the application. In this case the existing application will be removed, and the new one is advertised when the user next logs on to the machine.

Folder Redirection Tips and Tricks

The Folder Redirection extension to Group Policy is used to redirect such user-specific folders as My Documents from the client to a server, facilitating administrative management of user data.

  1. Let the system create folders for each user

    To ensure that folder redirection works as well as possible, create the root share only on the server, and let the system create the folders for each user. For the best experience, set the share permissions to Full Control for the security groups you're redirecting, and set the NTFS permissions for Everyone to Full Control, this folder, subfolders and files.

    If you must create folders for the users, ensure that you have the correct permissions set. The tables below shows the default and minimum permissions required for folder redirection.

    User Account

    Folder Redirection Defaults

    Minimum permissions needed

    Creator/owner

    Full Control, this folder, subfolders and files

    Full Control, this folder, subfolders and files

    Local Administrator

    Full Control, this folder, subfolders and files

    Full Control, this folder, subfolders and files

    Everyone

    Full Control, this folder, subfolders and files

    List Folder/Read data, Create Files/Write Data, Create Folders/Append Data - This Folder only

    Local System

    Full Control, this folder, subfolders and files

    Full Control, this folder, subfolders and files

    NTFS Permissions required for root folder

    User Account

    Folder Redirection Defaults

    Minimum permissions needed

    Everyone

    Full Control

    Use security group that matches the users who will need to put data on share

    Share level (SMB) Permissions required for root folder

    User Account

    Folder Redirection Defaults

    Minimum permissions needed

    %username%

    Full Control, owner of folder

    Full Control, owner of folder

    Local System

    Full Control

    Full Control

    Everyone

    Traverse Folder, Read Attributes, Read Extended Attributes and Read Permissions

    Everyone - no permissions

    NTFS Permissions required for each user's redirected folder

  2. Use offline folder settings on the server share where the user's info is stored

    This is especially important for users with laptops. Redirected folders of any type should be coupled with offline files. The recommended configuration for offline files to use is:

    · MyDocs:

    Autocaching for Documents or Manual Caching for documents (if you want users to have to "pin" files)

    · AppData:

    Autocaching for Programs

    · Desktop:

    Autocaching for Programs if the desktop is read-only

    · StartMenu:

    Autocaching for Programs

    For more info: User Data and User Settings Step-by-Step Guide, to be posted soon on TechNet.

  3. Incorporate %username% into fully qualified universal naming convention (UNC) paths

    This allows the system to easily create folders for users based on their username. For example, \\server\share\%username%\My Documents

  4. Have My Pictures follow My Documents

    This is advisable unless there is a compelling reason not to, such as file share scalability.

  5. Policy removal considerations

    Keep in mind the behavior your folder redirection policies will have upon policy removal. The Folder Redirection section of the online help gives details.

  6. Accept defaults

    In general, accept the default folder redirection settings.

  7. Don't store roaming profiles on the same server as redirected folders that are enabled for offline use

    When a share is unavailable, offline folders considers the whole server to be unavailable until the offline cache is manually synchronized. Roaming profiles will not be synchronized with the server while offline folders considers the server to be unavailable. If you are using offline folders in conjunction with folder redirection and roaming user profiles, you should ensure that the folder redirection share and the profiles share are located on different servers.

Offline Folders Tips and Tricks

  1. Do not put the server share in a Distributed File System (DFS) tree

    Using offline folders located in a Distributed File System (Dfs) tree is not supported. If you do put shares configured for offline use in a Dfs tree, unexpected behavior, such as Access Denied errors, may occur when moving from an offline to online state.

  2. Not all types of files can be synchronized

    By default .mdb and .pst files are not synchronized as they have other mechanisms of synchronizing.

  3. Don't store roaming profiles on the same server as redirected folders that are enabled for offline use

    See Folder Redirection Tips and Tricks for details.

  4. Leaving certain kinds of documents open can prevent entering standby mode.

    When using offline folders, the original versions of Microsoft Word 2000and Excel 2000 prevent the computer from going into standby mode when a document or spreadsheet is open. This is fixed in Office 2000 SR1.

User Profiles and Roaming User Profiles Tips and Tricks

Profiles are basic to the system and they were part of Windows NT 4.0. Generally they work and are configured in Windows 2000 as they did in Windows NT 4.0. When the user object is enabled with roaming user profiles, it is considered part of IntelliMirror feature set.

  1. If your users roam between Windows NT 4.0 clients and Windows 2000 clients, set the profile path during installation on Windows 2000

    For more info:

    • 224012 Using User Profiles with Both Windows 2000 and Windows NT 4.0<http://support.microsoft.com/support/kb/articles/224/0/12.ASP>

    • User Data and User Settings Step-by-Step Guide (coming soon to TechNet)

  2. Redirect the location of My Documents folder outside of the user's roaming profile.

    The best way is with folder redirection. If you don't have Active Directory enabled, you can do this with a logon script or instruct the user to do so.

    For more info: See User Data and User Settings Step-by-Step Guide (coming soon to TechNet)

  3. Do not use Encrypted File System (EFS) with roaming user profiles, offline folders, or File Replication Service (FRS).

    EFS is not compatible with roaming user profiles, offline folders, or FRS.

  4. Don't set disk quotas too low for users with roaming profiles

    If a user's disk quotas are set too low, roaming profile synchronization may fail. Make sure enough disk space is allocated to allow the system to create a temporary duplicate copy of a user's profile. The temporary profile is created in the user's context as part of the synchronization process, so it debits his or her quota.

  5. Don't use offline folders on roaming profile shares.

    Make sure that you turn off offline files for shares where roaming user profiles are stored. If you do not turn off offline folders for a user's profile, you may experience synchronization problems as both offline folders and roaming profiles try to synchronize the files in a user's profile.

    Note: This does not affect using offline folders with redirected My Documents etc.

  6. Don't store roaming profiles on the same server as redirected folders that are enabled for offline use

    See Folder Redirection Tips and Tricks for details.

  7. If roaming profiles are stored on a Windows NT 4.0 share, ensure that users are given "Full Control" share permissions.

    If you are using Windows 2000 Professional in a Windows NT 4.0 domain, and the server hosting the profile share is a Windows NT 4.0 computer, make sure that users are given Full Control share permissions. Not having the share permissions set to Full Control will result in profiles not synchronizing. The event log will contain errors such as :

    Event Type:

    Error

    Event Source:

    Userenv

    Event Category:

    None

    Event ID:

    1000

    Description:

     

    Windows cannot unload your registry file. If you have a roaming profile, your settings are not replicated. Contact your administrator.

    DETAIL -

    Access is denied.

This problem occurs because Change permission does not allow WRITE_DAC access, so the system can't copy ACLs. Windows 2000 copies Roaming Profiles ACLs, whereas Windows NT 4.0 does not.

Remote Installation Services Tips and Tricks

You use Remote Installation Services to install Windows 2000 onto remote computers over the network. The Windows 2000 source image can be customized, and can include applications.

  1. Use the appropriate number of Remote Installation Services servers on your network

    In a small local area network (LAN) --for example, one physical subnet without a router--a single Remote Installation Services server can serve all PXE remote boot-enabled client computers up to the network bandwidth, or server resource limitations. In branch office situations, where only slow links exist to the branch site, it may be worthwhile to physically locate a Remote Installation Services server at the branch site to avoid saturation of the slow link to that site. Because the PXE remote boot process is based on DHCP, routers between Remote Installation Services clients and Remote Installation Services servers must be configured to forward DHCP broadcasts in order for the client requests to be received and answered by the RIS server. For more information, see Working with routers in Using Remote OS Installation, Chapter25, Windows 2000 Server Deployment Guide<http://www.microsoft.com/technet/win2000/dguide/chapt-25.asp> in the Resource Kit.

  2. Restrict the number of installation options and operating system choices a user has access to within the Client Installation wizard

    By restricting the installation options, you increase the percentage of successful operating system installations without requiring assistance from technical support or administrative staff. By default, Remote Installation Services ships with only one installation option and operating system choice, both of which are selected by default without prompting users. For more information on client installation image options, see Installation options in the online help for Remote Installation Services.

  3. Use the Remote Installation Preparation wizard (RIPrep) image format to deploy a Windows 2000 Professional standard corporate desktop configuration across different types of client hardware throughout your organization

    Using the Remote Installation Preparation wizard, an administrator can replicate the installation image of an existing Windows 2000 Professional client computer, including locally installed applications and operating system configuration changes, to an available remote installation server on the network. After it is replicated, the installation image can be remotely installed by any supported client computer that uses the same hardware abstraction layer (HAL) as the source computer, regardless of other hardware differences between the source computer used to create the image and the destination computer installing that image. For more information, see Creating an installation image in the online help.

  4. Verify the versions of PXE ROMs in use on client computers

    Remote Installation Services requires a minimum version of .99L PXE ROMs in client computers to function correctly in all situations. Depending on the network interface card (NIC) brand and model and the implementation of RIS servers in your organization, PXE ROM revisions starting at .99C may work. If you experience difficulty, check the version of the PXE ROM in use, and if necessary contact the NIC or system vendor for an update.

  5. Use Remote Installation Services with computers that do not contain the PXE-based remote boot ROM

    Use the remote boot floppy generator (Rbfg.exe) to create a floppy disk for computers that do not contain the PXE-based remote boot ROM. You can then use the Remote Installation Services feature for these computers. For more information on the PXE-based remote boot ROM, see PXE architecture in the online help.

  6. Avoid non-ASCII characters when using the Client Installation wizard

    Limit the characters to only standard ASCII characters (OEM characters 32-127) for user name, password, or domain name information. The Client Installation wizard does not support extended ASCII character sets (such as those containing ü, é, and so on).

  7. Set appropriate rights to use RIS on existing computer accounts

    For details, see the knowledge base article 224294 Rights Needed for Remote Installation Server to Create Accounts<http://support.microsoft.com/default.aspx?scid=KB;en-us;224294&sd=tech>.

  8. Ensure you have appropriate rights to use RIS

    See these knowledge base articles:

    • 239004 How to Allow Non-Root or Enterprise Administrators to Authorize RIS Servers in Active Directory<http://support.microsoft.com/default.aspx?scid=KB;en-us;239004&sd=tech>

    • 238990 Service Control Point Error When Attempting to Add a RIS Server to the Domain<http://support.microsoft.com/default.aspx?scid=KB;en-us;238990&sd=tech>

  9. Enable debug mode to diagnose intractable RIS issues

    Verbose logging may sometimes be helpful. For instructions, see the knowledge base article: 236033 How to Enable Debug Mode for Remote Install Servers<http://support.microsoft.com/default.aspx?scid=KB;en-us;236033&sd=tech>. This should not be used during normal operation because it will reduce performance.

  10. Do not install the DHCP service only to authorize a RIS server

    If the RIS server is not going to be a DHCP server, do not install the DHCP service to authorize the RIS server. If the DHCP Management snap-in is only needed to authorize the RIS server, then install this snap-in by running adminpak.msi from %windir%\system32.

  11. Plan carefully when placing DHCP and RIS on the same server

    This may work out well in smaller environments but if you add another RIS server it will not be used, since PXE clients will get both IP and RIS server info from the existing servers. In other words, the original DHCP/RIS servers will continue to be overloaded.

    See the Knowledge Base article 250642 Some Office 2000 Desktop Icons Do Not Work on Restored RIPREP Images<http://support.microsoft.com/default.aspx?scid=KB;en-us;250642&sd=tech>.

Other Issues and Considerations

Adminpak.msi for Windows 2000 Professional

Users of Windows 2000 Professional should be aware that Windows 2000 Professional is primarily a client or standalone operating system. If you want to do system administration from a Windows 2000 Professional computer, you can install the Windows 2000 Administrative Tools Package, adminpak.msi, which is included on the Windows 2000 server CD-ROM. However, uninstalling the Tools package necessarily leaves some of the help files in place because they are identically named to their Windows 2000 Professional counterparts.

Issues Concerning Terminal Server, File Systems, and Other Windows Components

Many features of Windows 2000, and not only IntelliMirror features, require NTFS and won't work with FAT or FAT32 file systems.

For information about the following components, consult the Windows 2000 Server online help and the Windows 2000 Server Resource Kit:

  • Scripts

  • Internet Explorer Maintenance

  • Security Settings

Certain aspects of IntelliMirror work differently under Terminal Server. Consult the Terminal Server documentation and the Change and Configuration Management guide for more information. Also see the knowledge base article 217640 OFF2000: Setup Fails When Installing on Windows Terminal Server<http://support.microsoft.com/default.aspx?scid=KB;en-us;217640&sd=tech>.

Terminal Server and the Power Management features Suspend and Hibernate are incompatible. See the knowledge base articles APM Features Are Disabled with Terminal Services<http://support.microsoft.com/default.aspx?scid=KB;en-us;237551&sd=tech> and Power Options Icon Missing in Control Panel<http://support.microsoft.com/default.aspx?scid=KB;en-us;243651&sd=tech>.

When you try and install terminal services with offline files enabled you will get a message indicating that offline files will be disabled. Offline files is a machine feature and terminal services is a user feature.

Don't apply EFS (Encrypted File System) to your \temp directory as this can cause synchronization problems. Also, be aware that data made available through Offline Folders is not encrypted, even if the server uses EFS.

Disclaimer of Warranties and Limitation of Liabilities

Nothing contained herein modifies or alters in any way the standard terms and conditions of the purchase, lease, or license agreement by which the product was acquired, nor increases in any way the liability of the supplier of the software, its affiliates or suppliers ("the Supplier"). In no event shall the Supplier be liable for incidental or consequential damages in connection with or arising from the use of the product, the accompanying manual, or any related materials.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft