Skip to main content

Transparent Caching








Windows 7 keeps a cached copy of all files that a user opens


When you enable transparent caching, Windows 7 keeps a cached copy of all files that a user opens from shared folders on the local volume. The first time a user opens the file, the file is stored in the local cache. When the user opens the file again, Windows 7 checks the file to ensure that the cached copy is up to date and if it is, opens that instead. If the copy is not up to date, the client opens the copy hosted on the shared folder, also placing it in the local cache. Using a locally cached copy speeds up access to files stored on file servers on remote networks from the client. When a user changes a file, the client writes the changes to the copy of the file stored on the shared folder. When the shared folder is unavailable, the transparently cached copy is also unavailable. Transparent caching does not attempt to keep the local copy synced with the copy of the file on the remote file server as the Offline Files feature does. Transparent caching works on all files in a shared folder, not just those that you have configured to be available offline.


Transparent caching is appropriate for WAN scenarios and has several similarities to BranchCache. Some significant differences are that clients on the local area network do not share the cache and that file servers hosting the shared folders do not need to be running Windows Server 2008 R2 to support transparent caching. It is also possible to use transparent caching on clients running Windows 7 Professional and on clients that are not members of an AD DS domain, something that is not possible with BranchCache. Windows 7 triggers transparent caching when the round-trip latency value exceeds the amount specified in the Enable Transparent Caching policy


Before Windows 7, to open a file across a slow network, client computers always retrieved the file from the server computer, even if the client computer had recently read the file. With Windows 7 transparent caching, client computers cache remote files more aggressively, reducing the number of times a client computer might have to retrieve the same data from a server computer.


The first time a user opens a file in a shared folder, Windows 7 reads the file from the server computer and then stores it in a cache on the local disk. The second and subsequent times a user reads the same file, Windows 7 retrieves it from disk instead of reading it from the server computer.


To provide data integrity, Windows 7 always contacts the server computer to ensure the cached copy is up-to-date. The cache is never accessed if the server computer is unavailable, and updates to the file are always written directly to the server computer. Transparent caching is not enabled by default on fast networks.


IT Professionals can use Group Policy to enable transparent caching, to improve the efficiency of the cache, and to save disk space on the client, configuring the amount of disk space the cache uses and preventing specific file types from being synchronized.


These benefits are transparent to end-users and provide an experience for users at branch offices that more closely resembles the experience of being on the same LAN as servers. Additionally, the improved cache efficiency can reduce utilization across WAN links.


Microsoft TechNet Web page: http://technet.microsoft.com/en-us/library/dd637828.aspx.


Comments

Popular posts from this blog

SCCM Unknown computer not able to see Task Sequences after installing Current Branch 1702

Soon after installing SCCM CB 1702 we were unable to see Task Sequences deployed to the unknown collection. This issue was identified as a random system taking the GUID of the 'x64 Unknown Computer (x64 Unknown Computer)' record. As a result it was now a known GUID; as we were only deploying Task Sequences to the Unknown collection none were made available. 'x64 Unknown Computer (x64 Unknown Computer)' record 'x86 Unknown Computer (x86 Unknown Computer)' record To get the GUID of your unknown systems open SQL management studio and run the following command: --Sql Command to list the name and GUID for UnknownSystems record data select ItemKey, Name0,SMS_Unique_Identifier0 from UnknownSystem_DISC Using the returned GUID (SMS_Unique_Identifier0) we can find the hostname that has been assigned the 'x64 Unknown Computer (x64 Unknown Computer)' GUID by running the query below. --x64 Unknown Computers select Name0,SMS_Unique_Identifier0,Decommissioned0 from Sys

Windows 7 Offline files will not go Online when connected to network

Issue Several laptop users move between networks, domain, home, etc and when they attempt to access DFS shares explorer status is working offline.  The issue only resolves it self after a reboot. Connecting directly to the share works and i am able to ping network resources.  This behavior occurs for VPN users as well. Possible Causes "slow-link mode". In win7 (with default settings) a client will enter slow-link mode if the latency to the server is above 80ms. In slow-link mode all writes are made to the local cache and a background sync only happens every 6 hours.  Depending on your connection the default slow link detection speed is 64,000 bps On client computers running Windows 7 or Windows Server 2008 R2, a shared folder automatically transitions to the slow-link mode if the round-trip latency of the network is greater than 80 milliseconds, or as configured by the "Configure slow-link mode" policy. After transitioning a folder to the slow-link mode, Offline Fil

SCCM Software Update - Job error 0x80004005 Failed to Add Update Source for WUAgent

SCCM Software Updates - Failed to Add Update Source for WUAgent  Today I have been looking at a range of servers (Server 2008 /R2 2012 /R2) that were failing to communicate with the Software Update Point (SUP) in SCCM and retrieve deployment policy. The UpdateDeployment.log was reporting the Job error 0x80004005 Job error (0x80004005) received for assignment ({af7a48e6-d550-4070-dd9b-ecc234567584}) action UpdatesDeploymentAgent 12/6/2017 10:32:27 AM 2096 (0x0830) The WUAHandler.log  was reporting "Unable to read existing WUA Group Policy object" and "Failed to Add Update Source for WUAgent " Unable to read existing WUA Group Policy object. Error = 0x80004005. WUAHandler 12/6/2017 3:41:00 AM 2828 (0x0B0C) Failed to Add Update Source for WUAgent of type (2) and id ({3AAB6A76-CE2D-4E8A-9F11-123AE69612A1}). Error = 0x80004005. WUAHandler 12/6/2017 11:03:31 AM 2276 (0x08E4) Until the agent can report back to the SUP, SCCM will not be able to summarize Software Update sta