There are situations when moving documents using Explorer mode can retain the correct “Modified” timestamp in the browser, yet show an updated timestamp in Explorer Mode.

This is due to WebDAV showing the date associated with the File (SPFile) rather than the date associated with the SPItem. Explorer mode can update the modified date in the SPFile.

When you probe further, the “Item” has the correct timestamp (item[“Modified”] is in the local timezone. However the SPFile has a property called vti_timelastmodified that has the GMT timestamp.

Note the File has a property called vti_nexttolasttimemodified as well.

Both item.file.properties[“vti_timelastmodified”] and item[“Modified”] are the same type (DateTime) so I can compare them, which is precisely what I did in a special report looking for such timestamp divergence. I generated a filtered report custom written in PowerShell to show files that are more or less than 4 or 5 hours off (depending on the time of year, the hours diverge by either 4 or 5 hours) given my ET timezone. I only look to the “minute” and not the “second” on purpose, so I don’t flag false positives.
Here is how to fix a single instance of this issue:

$docurl = "http ://SharePoint/site/list/TimestampTest/test2.docx"
$site = New-Object Microsoft.SharePoint.SPSite($docurl)
$web = $site.OpenWeb()
$item = $web.GetListItem($docurl)
$list = $item.ParentList
 
[System.DateTime]$date = $item["Modified"]
 $user = New-Object microsoft.SharePoint.SPFieldUserValue($web, $item["Editor"])
 $item["Modified"] = $date;
 $item["Editor"] = $user;
 $item.Update()
 try { $item.Versions[1].delete() } catch {write-host -foregroundcolor red "Error (1) could not delete old version of $($item['Name'])"}

Here’s a function that reports on all URLs that suffer from this issue. Note the use of date comparison, and the check for timestamp being off by either 4 or 5 hours, and matching on the delta of both days and minutes:

function Reset-Dates ($WebUrl, $ListName)
{
 #Get web, list and content type objects
 $web = Get-SPWeb $WebUrl
 $list = $web.Lists[$ListName]
 IF ($ReportFile -eq $null) {$reportFile = C:report.csv"}
 
 #Check if the values specified for the content types actually exist on the list
 $xSit=$WebUrl;
 $xLis=$ListName;
 
 #Go through each item in the list
 $list.Items | ForEach-Object {
 $item = $_;
 
 $fd = $item.file.properties["vti_timelastmodified"]
 $id = $item["Modified"]
 
$dd = ($id-$fd)
 
$hoursMatch = (($dd.hours -eq -4) -or ($dd.hours -eq -5))
 $daysMatch = ($dd.days -eq 0)
 $minutesMatch = ($dd.minutes -eq 0)
 
 if ($hoursMatch -and $daysMatch -and $minutesMatch)
 {
 Write-Host '.' -NoNewline
 }
 else
 {
 $xURL=$item.url;
 $xNam=$item['Name']
 
 $xMod=$item["Modified"]
 $xfMod = $item.file.properties["vti_timelastmodified"]
 try {$xEdi=$item["ows_Modified_x0020_By"].replace("DOMAIN",$null)} catch {$xEdi=$item["ows_Modified_x0020_By"]}
 try {$xAut=$item["ows_Created_x0020_By"].replace("DOMAIN",$null)} catch {$xAut=$item["ows_Created_x0020_By"]}
 
 $Line1=$xURL+$sep+$xSit+$sep+$xLis+$sep+$xNam+$sep+$xAut+$sep+$xEdi+$sep+$xMod+$sep+$xfMod+$sep+$dd.days+$sep+$dd.hours+$sep+$dd.minutes+$sep+'1';
 $Line1 | Out-file -Filepath $ReportFile -Append
 $Line1=$null;
 }
 
}
 
$web.Dispose()
}

The primary naming convention to put in place is the Database Naming standard.  By default, SharePoint puts a GUID at the end of every database.

This is to ensure that two SharePoint farms can use the same database server without conflict. However the GUIDs make memorizing a database name practically impossible.

Here are some basic naming conventions to consider adopting:

• Avoid GUIDs at all costs
• Avoid blanks
• Avoid underscores
• Leave “DB” and “database” out of the name
• Use Capital Letters to highlight the start of words (CamelCase)
• Consistent description to allow a database to be clearly associated with a specific Web App and Service App
• References to Production vs. Development are not necessary
• References to SharePoint version are not necessary
• References to “SharePoint” are unnecessary, especially for a dedicated SQL Server
• Leave the obscure “WSS” SharePoint convention for content databases, instead use “Content” at the start of the database name.  That’s clearer for DBAs who are not versed in the mysterious acronyms of SharePoint.

Here’s a proposed syntax for structuring database names:

[Major Application][Type] [Minor Application] [Specific]

Examples

Default: Search_Connector_CrawlStoreDB_4040b7300e9e42779edb3e6b926be5a7

New: ServiceApp_SearchConnectorCrawlStoreDB

Default: SharePoint_AdminContent_ff35d171-482c-4f9d-8305-a4a259ec1a15

New: Content_CentralAdmin

Default: wss_content_eaee9d8f-ed75-4a56-bad3-5abf232b4f66

New: Content_ DIV_HR

Default: StateService_0f2a42e8b90d4c60830ca442e753de13

New: ServiceApp_State

Key SharePoint Limits

Microsoft publishes a long list of soft and hard boundaries and limits within SharePoint. These have not changed significantly between 2010 and 2013. The definitive list can be found at: https://technet.microsoft.com/en-us/library/cc262787.aspx

An example of a hard boundary limit is the 2GB limit on file size. This limit is based on Operating System and SQL Server limits, and involves no trade-off options. However it is not advisable to allow for 2GB uploads, without first considering the options and tradeoffs involved, as well as end-user performance, and configuration settings such as BlobCache that can alleviate some of the delays associated with huge files.

An example of a soft limit is the List View threshold of 5,000 that prevents any list from trying to display more than 5,000 items. Even trying to display 5,001 will return an error. This setting is easily changed, but the impact can be significant, as the underlying SQL Server changes from row locking and imposes table locking on edits of over 5,000 items. This is an example of trading off performance and scalability with any usability benefits of increasing this setting. There are situations where it may make sense, such as a farm with a disproportionately low number of concurrent users, leading to a good trade-off of table locking with a low likelihood of another user being concurrently impacted. However, for a larger number of concurrent users, you definitely do not want to increase this threshold, without causing likely and noticeable performance degradation.

While there are a large number of limits, the ones that are most likely to guide your design are the two listed above, plus Security Scopes and Content Database size.

Security Scopes in a Library

Each time an object (web, library, folder or item) gets unique security permissions, that is termed a “Security Scope”. If 100 documents are assigned unique permissions, but have the same three people as contributors, this still counts as 100 Security Scopes. If they are each assigned to 200 Contributors, that still is only 100 Security Scopes. A rule of thumb is once you reach 1,000 unique Security Scopes, performance degrades 20%. Increase the number further, and performance nosedives. If you are going to have large libraries, it is best to have few or no unique Security Scopes. This is purely a performance impact, and the result is noticeable.
Content Database Size
This has the most direct impact on your DR strategy. The limits of your hardware (bounded by laws of physics) determine the speed of your backups and restores. The larger the Content Database, the longer your backup and recovery. A prime example is restoring a single Content Database. The scenario is a user “stomps” on a document, replacing it completely, using Explorer Mode. You’ve got to restore from a backup, you start the restore and get ready to do an unattached database extract, and are waiting for the restore to complete. However the large Content Database of 200GB or more requires the better part of a day to restore, or worse, you have insufficient spare disk space for the restore.

URL Length

Aside from the published limits, there’s a crucial limit that is not listed in the SharePoint Boundaries and Limits site, which is the maximum length of a URL of 255. That might sound like a large URL, but once you use a FQDN (Fully Qualified Domain Name) for your Web Application, a Managed Path, Sites and SubSites, Libraries and Nested Folders, enterprising users will utilize longer file names than you’d imagine, sprinkling them with characters not easily represented in a URL (such as blanks), causing them to be expanded to %20 (hex of ASCII 32, which is a blank). This limitation is insidious. Your design could appear to work fine…until users encounter seemingly random problems, where only some files have issues. Renaming files and folders tersely can buy some relief, replacing blanks with underscores, or getting users to use CamelCase is a tough sell to end users used to naming files as they want.

Impact of Design Decisions

Design decisions can be made implicitly that have a great impact on scalability, performance and DR. Let’s summarize these key decisions:

• Web Applications
  The fewer the better. Aside from the untouchable Central Admin Web Application, and separate MySites, try to limit your Web Applications. Each Web Application carries not only its own configuration, but also a whoel raft of dedicated Timer Jobs firing multiple jobs every second, and additional IIS load, even if you share an Application Pool among multiple Web Applications.
• Managed Paths
  These are defined at the Web Application level, and provide the structure for additional Site Collections.
• Host Named Site Collections
  Aside from perhaps Search, this is the largest infrastructure change in SharePoint 2013. It’s geared to allow for cloud based multi-tenancy, and scalability beyond what can be done with the relatively structured Managed Paths. Best is to select one Web Application, and use that for all Host Named Site Collections.
•  Number of Site Collections
  Some users feel comfortable within the confines of a single site collection. There are certainly conveniences within a site collection, including shared security groups, shared content types, and an immediate navigable hierarchy. Going with monolithic Site Collections limits your ability to scale across Content Databases, as a Site Collection can only ever exist within one Content Database. Once a Site Collection has grown too large, splitting it can be fraught with challenges. A large Content Database takes proportionately longer to backup, and more importantly, to recover.
• Number of Sites
  A more diverse set of Sites (SPWeb objects, not to be confused with Site Collections) and their hierarchy requires thoughtful design to echo how users typically navigate SharePoint. A greater number of sites is recommended, which in turn should allow for scalability.
• Number of Libraries
  Huge libraries suffer a proportionate impact to performance, and expose the possibility of errors if a View returns a result set larger than the List View Threshold (default and recommended setting of 5,000). It is better to guide users to replace a desired set of top level folders instead with libraries.

Going with a more diverse yet coherent and logical structure of Site Collections, Sites, and Libraries will allow for the scalability your farm needs to satisfy daily user needs, as well as growth  objectives.

A good approach when working with users is to play down the name (site collection, site, library and folder) and focus instead on the hierarchy, which users understand. You can always tune navigation to give them an optimal experience.