Saving a Site Template with activated Publishing Feature is not possible in SharePoint 2013 (menu link missing).
When using the direct browser link (which worked perfect in SharePoint 2010) http://YourSharePointSite/_layouts/15/savetmpl.aspx you get the error The "Save site as template" action is not supported on this site.
Modify the SaveSiteAsTemplateEnabled property in your SPWeb object via PowerShell.
# Store your Site in a variable: $SiteToModify = Get-SPWeb http://YourSharePointSite # Display the current value of the property: $SiteToModify.AllProperties["SaveSiteAsTemplateEnabled"] # Set the property to true: $SiteToModify.AllProperties["SaveSiteAsTemplateEnabled"] = "true" $SiteToModify.Update()
When now trying the savetmpl.aspx link again, you can save your template: http://YourSharePointSite/_layouts/15/savetmpl.aspx
The following PowerShell scripts have been published by our Exchange and Office 365 experts to the technical community at TechNet Gallery. Please use the GitHub repositories to report issues or to file feature requests.
Please send comments, wishes, and ideas to support@granikos.eu.
Enjoy!
Need assistance with your Exchange Server Organization? You plan to upgrade your Exchange Server Organization? You plan to migrate to Office 365? Contact us: info@granikos.eu
Update 2020-10-05: Fetch all remote SMTP servers from Exchange receive connector logs added Update 2020-05-25: TechNet Gallery links removed due to end of TechNet Gallery in mid-2020 Update 2020-02-07: Report for enabled client protocols, Exchange Environment Report - v2, Set thumbnailPhoto for AzureAD guest users added Update 2019-05-07: Export mailbox delegates and SMTP forwarding information added Update 2018-09-04: Add remote IP-address ranges to a receive connector added Update 2018-06-16: Manage Master Category List for Shared Mailboxes and Teams added Update 2018-04-29: Convert Word documents using PowerShell and Set Mailbox Item Private Flag added Update 2018-01-24: Create a new Room Mailbox with Security Groups added Update 2017-11-11: Export all user mailbox permissions added Update 2017-09-22: Remove Out-Of-Office rules from user mailbox added Update 2017-05-20: Parse email messages content for further processing and Update OWA vDir config across multiple servers added Update 2017-03-18: Fetch recently created public folders and Clear Private Flag on Mailbox Messages added Update 2017-02-22: Remove Orphaned HealthMailbox and SystemMailbox Accounts from MESO Container added Update 2017-02-17: Test Office 365 Domain Availability added Update 2017-02-13: Connect to Exchange Server 2013+ using remote PowerShell added Update 2017-02-07: Create Exchange internal/external Url based certificate requests, Create a scheduled task for Exchange Server 2013 added Update 2017-01-24: Gather Exchange Configuration Data added Update 2017-01-05: Export Messages from Transport Queue added Update 2016-11-29: Clean legacy public folder ACL added, Scripts categorized Update 2016-11-28: Add multiple legacy public folder replicas added Update 2016-08-18: Simple import of multiple PST files for a single user added Update 2016-07-28: Change IIS Log File settings Github Url added, Create a new Team Mailbox with Security Groups added Update 2016-06-04: GlobalFunctions added Update 2015-06-18: Copy-ReceiveConnector updated Update 2015-06-01: Exchange 2010 Public Folder Replication Report (UTF8 support) Update 2015-05-21: Copy anti-virus pattern to Exchange 2010/Exchange 2013 servers added Update 2014-12-10: Copy a receive connector from one Exchange Server to multiple Exchange Servers added
When setting up Exchange Server or any other Enterprise application that provides IIS services (i.e. SharePoint), it might be a requirement to change the default folder path für IIS log files to a different location than the default location (C:\inetpb\logs). Even though todays physical or virtual system drives are in the 100GB range, it might be a design requirement to have the folder path placed on a different volume.
Especially when you have to configure more than one server, you prefer to have configurations implemented by script.
The script Set-Webserver.ps1 provides in its current release the configuration of:
Additional configurations, like logExtFileFlags, logFormat, truncateSize, can be implemented, if required.
The script runs on Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2.
How many characters should have a password in order to be considered safe?
Office 365 limits the password length for users not synchronized with on-premise Active Directories to 16 characters. Can this considered to be safe?
Office 365 administrators need to be aware of the fact that the new Administrative Tools do not show a warning when a new user is created. When pasting an initial password into the textbox, no warning is displayed. But the password itself has already shortened to 16 characters automatically.
The summary page shows the shortened password after the new user has been created. The administrator needs to pay proper attention to the status summary to notice the shortened password.
When logging in for the first time the user experience is different. The user is notified that the password cannot exceed 16 characters.
Microsoft should rethink the limitation of 16 characters to enhance the security level for user login.
Today's virtualization options provide a wide variety to even virtualize business-critical enterprise applications. Distributed enterprise applications can easily be virtualized but require proper planning. Otherwise, you will end up with virtualized SharePoint Server Farm that does not scale well and perform badly.
This article will provide information on how to virtualize your production environment properly and will not necessarily cover development environments, as those tend to run in over-committed scenarios anyway.
The following table provides a simple overview of the SharePoint farm terminology:
Never ever start a SharePoint production deployment with a single multi-role SharePoint Server.
The following figure illustrates the architecture of a SharePoint Server 2013 environment example.
Capacity and Performance: These two key aspects are the most important aspects when you plan your SharePoint virtualization infrastructure. You need to plan for enough disk capacity to host all of the content databases and data that is cached to disk by the web server and application server roles. Your overall capacity should be planned at least for a three year period. The requirements for CPU and memory sizing of the virtual hosts depends on your server requirements. A virtual host should always be equipped to the physical maximum. If you leave CPU sockets empty, there is no guarantee that you will get the CPU for that socket in the future. The memory banks should be filled in the proper ratio per CPU as well. Otherwise, you will not be able to fully benefit from the virtualization of your servers.
Mostly all of the major vendors of hardware load balancers offer virtualized load balancers as well. As long as the virtual load balancer is not running on an over-committed host, and sufficient performance is provided, there is no legitimate reason to not virtualize a load balancer.
Especially when you maintain a large virtualization platform you are heavily interested to not add additional hardware complexity to your network infrastructure by adding hardware load balancers. Any additional layer of complexity adds an additional layer for support as well.
Some of the major vendors are (purely alphabetical):
Web servers are easy to scale because web servers generally provide much better performance by adding additional CPUs and memory resources. This is the reason why the webserver role within a SharePoint deployment is the easiest to scale out. Because it is so easy to just add additional resources it is not automatically the right approach. Performance-wise you will reach a point where adding an additional web server makes more sense. This decision if you extend the resources of an existing server or add a new virtual machine depends on the overall virtualization infrastructure and the available hardware resources.
Another important topic to think about is the migration of virtual machines between hosts and the high-availability functionality of your virtualization platform. A virtual machine can be moved between virtual hosts more quickly when the virtual machine is not over-sized. The larger the assigned resources are, the more time it takes to migrate a virtual machine. You need to keep this in mind not only for migrations due to maintenance reasons or virtual hosts fail-overs. The same is true when you utilize the automatic load balancing of virtual machines.
NUMA nodes are an additional important topic. Microsoft provides dedicated information to NUMA nodes SharePoint here. Even though the article is focusing on Hyper-V, the general NUMA node requirements are valid for other hyper-visor platforms as well. As per Microsoft performance can decrease by up to 8% when a virtual machine needs to access remote memory from another NUMA node.
The proper sizing of memory resources ensures that your web servers perform as expected. You need to ensure that the webserver does not require to swap memory and make heavy use of the page file. Any use of the page file results in unnecessary disk I/O. And depending on the disk subsystem the required I/O reduces the performance dramatically. Even though the operating system supports the hot-adding of virtual memory, not all application functions make use of added virtual memory. Some components recognized available memory during the start-up of the operating system and do not adjust themselves during run time (e.g. Distributed Cache).
Your SharePoint server running the webserver role should be configured with at least:
The CPU demand of SharePoint application servers depends heavily on the applications that are running on those servers. Some applications might be more CPU resource-intensive (e.g. Search), others might be more memory intensive. To find the proper sizing for your specific requirements you need to monitor the system resources not only on a general level (e.g. System CPU usage, system memory consumption) but on a more granular level (per service, per application pool, per worker process).
Your SharePoint server running the application server role should be configured with at least:
The virtualization of SQL Server is a separate topic that will be covered in more detail in a separate blog article. But it would be unfair to leave this section more or less empty.
First of all, it should be said that even SQL Server can be virtualized. If virtualizing SQL Server is an option for your IT infrastructure depends on the SQL Server and data warehouse design of your company. Some companies prefer to host SQL databases in central SQL Servers serving all data applications within the company. Other companies prefer to host SQL databases on different SQL servers and group those by SQL Server SLA and/or by the type of data stored in databases.
In this example, we assume that there are three SQL Server 2012 dedicated to SharePoint in use. The following table gives a brief overview of the recommended memory sizing for SQL Server virtual machines:
SQL Server 2012 provides a new functionality called AlwaysOn Availability Groups (AAG). The AAG provides a much better experience and performance when it comes to database fail-overs. But at the same time, you need to plan resource requirements in a different way than you were used to with classic Windows Clustering capabilities. An AAG does have a primary replica of a database and many secondary (passive) replicas of the same database.
AAGs can be operated in two different availability modes:
In our example we have two different AlwaysOn Availability Groups configured:
The SharePoint 2013 farm example ends up in the following virtual host demands:
3 x 100 GB (OS, SQL Server) 3 x 1 TB (Databases)
To be able to have a single virtual host in maintenance, but still have redundancy we need to plan for at least three virtual hosts. But even in this case one of the two can fail. Therefore you need to protect yourself from a failure while having on a virtual host in maintenance. The disk subsystem is connected to each host by fiber channel or iSCSI on a dedicated 10GB network.