Abstract: The techniques described herein facilitate scope-based certificate deployment for secure dedicated tenant access in multi-tenant, cloud-based content and collaboration environments. In some embodiments, a method is described that includes receiving an incoming authentication request from an access system, wherein the authentication request includes metadata, extracting the metadata from the authentication request, and processing the metadata to identify a tenant corresponding to the request. A tenant-specific certificate associated with the tenant is then accessed and provided to the access system for validation by a third-party certificate authority.

Abstract: Various systems and methods for domain authentication are described herein. In an example, the method may include detecting a domain from a request of a tenant for access to a farm. The method may also include identifying a presence of a site ID from a database of the farm based on the domain. The method may also include sending an authentication request to a default site or a custom site, the authentication request managed through a site manager based on the identified presence of the site ID in the database of the farm. The method may also include routing traffic from the tenant to the farm in response to satisfaction of the authentication request.

Abstract: The techniques described herein facilitate scope-based certificate deployment for secure dedicated tenant access in multi-tenant, cloud-based content and collaboration environments. In some embodiments, a method is described that includes receiving an incoming authentication request from an access system, wherein the authentication request includes metadata, extracting the metadata from the authentication request, and processing the metadata to identify a tenant corresponding to the request. A tenant-specific certificate associated with the tenant is then accessed and provided to the access system for validation by a third-party certificate authority.

Abstract: In one example, a server farm patching system may wait until fewer users are accessing a server farm to apply a patch code set to a server application executed by a server at the server farm. The server farm patching system may identify an off-peak usage time range for a server farm describing when the server farm has an activity level below an activity threshold. The server farm patching system may apply a patch code set at an off-peak usage patching aggressiveness level indicating an off-peak upper bound percentage of servers in the server farm receiving the patch code set when within the off-peak usage time range. The server farm patching system may apply the patch code set at a peak usage patching aggressiveness level indicating a peak upper bound percentage of servers in the server farm receiving the patch code set when outside the off-peak usage time range.

Abstract: The techniques described herein facilitate scope-based certificate deployment for secure dedicated tenant access in multi-tenant, cloud-based content and collaboration environments. In some embodiments, a method is described that includes receiving an incoming authentication request from an access system, wherein the authentication request includes metadata, extracting the metadata from the authentication request, and processing the metadata to identify a tenant corresponding to the request. A tenant-specific certificate associated with the tenant is then accessed and provided to the access system for validation by a third-party certificate authority.

Abstract: Various systems and methods for domain authentication are described herein. In an example, the method may include detecting a domain from a request of a tenant for access to a farm. The method may also include identifying a presence of a site ID from a database of the farm based on the domain. The method may also include sending an authentication request to a default site or a custom site, the authentication request managed through a site manager based on the identified presence of the site ID in the database of the farm. The method may also include routing traffic from the tenant to the farm in response to satisfaction of the authentication request.

Abstract: In one example, a server farm updater may schedule application of a software change to a server farm based on a farm temperature value representing a dynamically determined level of customer interaction with the server farm. A server farm updater may maintain a customer profile for the server farm describing a customer interaction with the server farm. The server farm updater may apply a farm temperature describing a server farm usage based on the customer profile. The server farm updater may apply the software change to the server farm based on the farm temperature.

Abstract: The techniques described herein facilitate scope-based certificate deployment for secure dedicated tenant access in multi-tenant, cloud-based content and collaboration environments. In some embodiments, a method is described that he includes receiving an incoming authentication request from an access system, wherein the authentication request includes metadata, extracting the metadata from the authentication request, and processing the metadata to identify a tenant corresponding to the request. A tenant-specific certificate associated with the tenant is then accessed and provided to the access system for validation by a third-party certificate authority.

Abstract: In one example, a server farm patching system may wait until fewer users are accessing a server farm to apply a patch code set to a server application executed by a server at the server farm. The server farm patching system may identify an off-peak usage time range for a server farm describing when the server farm has an activity level below an activity threshold. The server farm patching system may apply a patch code set at an off-peak usage patching aggressiveness level indicating an off-peak upper bound percentage of servers in the server farm receiving the patch code set when within the off-peak usage time range. The server farm patching system may apply the patch code set at a peak usage patching aggressiveness level indicating a peak upper bound percentage of servers in the server farm receiving the patch code set when outside the off-peak usage time range.

Abstract: A cyclical patching process associated with a cloud application may be defined to ensure high availability (HA) of the cloud application in order to prevent impacting an availability to end users. A list of server identities corresponding to one or more servers of a datacenter hosting the cloud application may be accepted. HA metric values for each of the server identities may be determined in order to compute an overall HA metric value for the cloud application. A subset of the servers may be removed from a rotation framework of the cloud application based on the determined HA metric values, where the removal does not affect the overall HA metric value of the cloud application. One or more patches may be applied to each server within the subset of servers in parallel, and the subset of servers may be reinstated in the rotation framework of the cloud application.

Abstract: In one embodiment, a network system may be upgraded without losing access to write privileges to a network file 122 during the system upgrade. A network file management system 120 may execute a system upgrade. A network file management system 120 may provide direct write access for a data file 122 to a user throughout the system upgrade.

Abstract: Requests to a server farm are managed in an application intelligent manner based on server health and client information. A request management (RM) module is configured to make smart routing decisions, based on routing rules that relate the nature of requests to a dynamic topology of a server infrastructure. The RM may use its knowledge of server applications, servers, and clients to deny potentially harmful requests from entering the service, route good requests to the suitable machines, and maintain a history of the decisions and consequences automatic and/or manual optimization.

Abstract: A cyclical patching process associated with a cloud application may be defined to ensure high availability (HA) of the cloud application in order to prevent impacting an availability to end users. A list of server identities corresponding to one or more servers of a datacenter hosting the cloud application may be accepted. HA metric values for each of the server identities may be determined in order to compute an overall HA metric value for the cloud application. A subset of the servers may be removed from a rotation framework of the cloud application based on the determined HA metric values, where the removal does not affect the overall HA metric value of the cloud application. One or more patches may be applied to each server within the subset of servers in parallel, and the subset of servers may be reinstated in the rotation framework of the cloud application.

Abstract: Deployment of builds of upgrade, patches, and the like may be orchestrated using tables that reside outside the scope of any one environment, but that is accessible by the environments. The tables may define the activities that are pending or running in the system, as well as the dependency chains that prevent activities happening out of safe order (for example, a deployment happening on paying customers before happening in test environments). When a new build is available for deployment, it may be detected and new activities for that build listed as pending in the affected environments. Any activities having no prerequisite dependencies may start immediately, while those with prerequisites may wait for the prerequisite activities to be completed. The encoding of dependencies between activities and across environments may enable access to those from any deployment environment.

Abstract: In one embodiment, a patch application system 330 for a server farm 310 may be programmatically integrated with a monitoring service 340 to allow for prompt reaction to a patching error. The patch application system 330 may implement a patch application 500 to a server farm 310. The patch application system 330 may receive an error notice 600 describing a patching error from a monitoring service 340. The patch application system 330 may automatically execute a response action to the patching error.

Abstract: In one embodiment, a network system may be upgraded without losing access to write privileges to a network file 122 during the system upgrade. A network file management system 120 may execute a system upgrade. A network file management system 120 may provide direct write access for a data file 122 to a user throughout the system upgrade.

Abstract: Server health and client information are exchanged through headers for request management. Headers in standardized or proprietary protocol communication between servers and a request management module and/or clients and the request management module may be used to exchange server health and client information. The exchanged server health and/or client information may be employed in throttling, routing, and/or load balancing the incoming requests. Rules specified by the client through the header exchange may also be used for throttling, routing, and/or load balancing decisions.

Abstract: Requests to a server farm are managed in an application intelligent manner based on server health and client information. A request management (RM) module is configured to make smart routing decisions, based on routing rules that relate the nature of requests to a dynamic topology of a server infrastructure. The RM may use its knowledge of server applications, servers, and clients to deny potentially harmful requests from entering the service, route good requests to the suitable machines, and maintain a history of the decisions and consequences automatic and/or manual optimization.

Abstract: Server health and client information are exchanged through headers for request management. Headers in standardized or proprietary protocol communication between servers and a request management module and/or clients and the request management module may be used to exchange server health and client information. The exchanged server health and/or client information may be employed in throttling, routing, and/or load balancing the incoming requests. Rules specified by the client through the header exchange may also be used for throttling, routing, and/or load balancing decisions.

Abstract: Requests to a server farm are managed in an application intelligent manner based on server health and client information. A request management (RM) module is configured to make smart routing decisions, based on routing rules that relate the nature of requests to a dynamic topology of a server infrastructure. The RM may use its knowledge of server applications, servers, and clients to deny potentially harmful requests from entering the service, route good requests to the suitable machines, and maintain a history of the decisions and consequences automatic and/or manual optimization.