Diese Präsentation ist der erste Teile eines Workshops zum Thema AD FS und Office 365.
In diesem ersten Teil wird ein Überblick zu den Active Directory Federation Serverice geboten. Betrachtet werden die Entwicklung von AD FS, die Voraussetzungen für einen sicheren Betrieb und Darstellung von Best Practices.
Das Blog Cumulative Update für Dezember 2017 (CU1217) fasst interessante Themen rund um Cloud Sicherheit, Exchange Server, Office 365, Azure und Skype for Business (aka Lync) des Monats Dezember 2017 zusammen.
Gerne unterstützen wir Sie bei der Planung und Durchführung Ihrer Exchange Server Implementierung oder Migration.
Sie denken über einen vollständigen Wechsel zu Office 365 oder eine Hybrid-Konfiguration mit Office 365 nach? Wir beraten Sie umfassend und neutral über die Möglichkeiten der Office 365 Plattform.
Sie möchten mehr über Exchange Server 2016 erfahren? Gerne erläutern wir Ihnen die technischen Änderungen und Chancen für Ihr Unternehmen in einem individuellen Workshop.
Weitere Informationen zu unseren Dienstleistungen finden Sie auf unserer Website (https://www.granikos.eu) oder Sie kontaktieren direkt unser Vertriebsteam: firstname.lastname@example.org
When it comes to monitoring application administrators often disagree with system administrators on what to monitor and which thresholds to configure. By nature system administrators focus on system related counters and objects to monitor. They do not care about application related monitoring as those information's are out of scope of their daily work. Vice versa the same is true for application administrators.
Therefore there is no and will never be a single monitoring solution to combine totally different interests in information. On the other hand the business is highly interested in implementing a single monitoring solution to reduce the overall licensing cost (priority 1), reduce the number of servers required to host monitoring solutions (priority 2) and to eliminate the need for technical training (priority 3).
System monitoring and application monitoring systems sometimes share an intersecting set of “things” they are able to monitor. The fact is that both monitoring approaches have totally different procedures on how to monitor.
The following diagram illustrates the system monitoring approach, where a probe connects to a target and queries data using a dedicated protocol supported by the target (e.g. SNMP, WMI, SSH, etc.).
The solution illustrated uses PRTG which is a network monitoring solution that supports all standard protocols for monitoring. It can be enhanced by individual scripts, programs and libraries. You can find a link to PRTG at the end of this post.
In comparison to system monitoring the application monitoring approach looks very different, as the following figure shows:
Application monitoring relies on the existence of agents installed locally on the servers hosting the applications. This approach provides the ability to monitor from an application perspective. The agent itself performs checks depended on the application running on the same server. For example the agent checks that DNS name resolution works using the configured DNS servers on the server. If DNS resolution does not work the agent responds with an error to central management even when the DNS server itself is reachable by the system monitoring probe.
In the current IT landscape where messaging and collaboration solutions provide business functionality at a large scale and are setup in high-availability configurations the monitoring of such implementations from an application perspective is crucial. In a world where “always on” is the business goal for a mobile work force downtime of messaging and collaboration systems is an issue.
The ENow Management Suite supports your monitoring efforts for:
Mailscape is the part of the ENow Management Suite which helps you to monitor the messaging infrastructure components like Exchange Server, Blackberry Enterprise Server and SMTP relay servers.
Mailscape 365 is part of the ENow Management Suite which monitors your Exchange Online and Hybrid Exchange deployment inclusive of required hybrid components like AD FS and DirSync.
Compass is the part of the ENow Management Suite which monitors domain controllers and Active Directory specific topics.
ForeSite is the part of the ENow Management Suite which monitors your SharePoint farms and the related SQL database servers.
Besides monitoring the vitals of the application components and the infrastructure requirements (network, AD, etc.) the solution provides an extensive reporting functionality. The default set of reports fits most reporting requirements, but you can set up your own reports as well. A significant feature is the ability to provide the reports to different groups of stakeholders.
Monitoring servers should not be a time consuming task for an application administrator. Therefore the interface of the ENow Management Suite is quite handsome, as it displays all statuses in a dashboard. As long as all statuses are green the application administrator can focus on other work. When using all parts of the ENow Management Suite you act within one single dashboard, but each part utilizes it’s own security groups for access the dashboard.
How does a SharePoint administrator work with ForeSite?
The follow screenshot shows the ForeSite dashboard:
If the dashboard uses a traffic light approach to signal good, warning and error states. This makes it really easy to focus on section of the application infrastructure where some is not in a healthy state. It cannot be any more intuitive.
By just clicking on the signaling rectangle you dig deeper to the next level of information:
It seems as if there is something wrong with a SharePoint timer job. But what is going on?
Ok, it is not the SharePoint timer service itself. It is just one of the timer jobs itself.
The Application Addressed Refresh Job is offline since 3.4 days. That is a valuable information and the SharePoint administrator knows where to start to solve this issue.
This is a basic example how an application monitoring solution can help to identify the error.
The reporting functionality of ForeSite helps to gather a lot of different data from a SharePoint farm. Those reports can be executed manually or be sent automatically by email on a recurring basis. The reports overview displays a list of different reports which are available by default:
With the proactive monitoring of critical SharePoint services, like Site Availability, Timer Jobs, Search and Index, and content databases ForeSite helps the application administrator to focus on daily work. The alerting functionality helps to reduce the response time in the case of an error and therefore helps to reduce the overall business impact to a minimum.
The classic system monitoring solution is the interface of the administrative personnel responsible for the IT infrastructure itself. The application monitoring solution is the main interface for application administrators and runs on top of the IT infrastructure. Even when some components (disk, memory, CPU, …) are measured by both components.
Besides monitoring of different important aspects of the application an application monitoring solution provides the ability for application specific reports. Those reports and even the dashboard itself can be made available to different groups of stakeholders in the company using Windows credentials.
An application monitoring and reporting solution is a valuable addition to classic system monitoring.
What are your thoughts on system and application monitoring? Leave a comment.
Get your free 21-day trial of the ENow Management Suite today: http://www.granikos.eu/en/Products/ENowManagementSuite
Need more professional consulting on Exchange Server, Office 365 or Exchange configurations? Do not hesitate to contact us by email: email@example.com
Das Exchange Blog Cumulative Update für Januar 2017 (CU0117) fasst interessante Themen rund um Exchange Server und Office 365 (Exchange Online), Azure und Skype for Business (aka Lync) des Monats Januar 2017 zusammen.
Sie denken über einen vollständigen Wechsel zu Office 365 oder eine Hybrid-Konfiguration mit Office 365 nach? Wir beraten Sie umfassend und ausführlich über die Möglichkeiten der Office 365 Plattform.
Sie möchten mehr über Exchange Server 2016 erfahren? Gerne erläutern wir Ihnen die technischen Änderungen und Chancen für Ihr Unternehmen in einem persönlichen Workshop.
Das Exchange Blog Cumulative Update für Dezember 2016 (CU1216) fasst interessante Themen rund um Exchange Server und Office 365 (Exchange Online), Azure und Skype for Business (aka Lync) des Monats Dezember 2016 zusammen.
Das Exchange Blog Cumulative Update für Januar 2016 (CU0116) fasst interessante Themen rund um Exchange Server und Office 365 (Exchange Online), Azure und Skype for Business (aka Lync) des Monats Januar 2016 zusammen.
Sie möchten mehr über Exchange Server 2016 erfahren? Gerne erläutern wir Ihnen die technischen Änderungen und Möglichkeiten für Ihr Unternehmen in einem persönlichen Workshop.
Weitere Informationen zu unseren Dienstleistungen finden Sie auf unserer Website (https://www.granikos.eu) oder nehmen Sie direkt mit uns Kontakt auf: firstname.lastname@example.org
Today's virtualization options provide a wide variety to even virtualize business critical enterprise applications. Distributed enterprise applications can easily be virtualized but require a 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 provide a simple overview on 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 server generally provide a much better performance by adding additional CPUs and memory resources. This is the reason why the web server 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 host 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 informations to NUMA nodes SharePoint here. Even though that the article is focusing in 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 machines 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 web server 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 sub system the required I/O reduces the performance dramatically. Even though that the operating system supports hot-adding of virtual memory, not all application functions make use of added virtual memory. Some components recognized available memory during start-up of the operating system and do not adjust themselves during run time (e.g. Distributed Cache).
Your SharePoint server running the web server 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 application 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 application 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.
AGGs 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 follow 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 virtual host in maintenance. The disk subsystem is connected to each host by fibre channel or iSCSI on a dedicated 10GB network.