Abstract: Storage access requests are received from one or more applications. Multiple servers update multiple virtual disks as directed by the storage access requests. The virtual disks store data that is write order dependent across the virtual disks. Logs are associated with the virtual disks. Information associated with each storage access request is stored in one of the logs. A cycle of log switching is performed. A write order consistent tracking coordinator coordinates the log switching with agents at the servers to maintain request ordering. Replication coordinators coordinate the application of the switched-out log files from primary storage to replica storage, creating a write-order consistent point on the replica side matching the primary side, and providing for failure resiliency regarding transfer of the logs. The replication logs may be received individually on the replica side from the servers on the primary side to enable highly scalable parallel/simultaneous transfers of the logs.

Abstract: Methods and systems are disclosed in which inherited activation opens a secure communication path from the host operating system (OS) to the guest (virtual machine) OS. The license state of the software on the host is passed through this channel, and software installed in the guest uses this information to inform its own product activation process. The virtualized (guest) software may then activate without any outside communication when the license requirements for the host are met.

Abstract: Storage access requests are received from one or more applications. Multiple servers update multiple virtual disks as directed by the storage access requests. The virtual disks store data that is write order dependent across the virtual disks. Logs are associated with the virtual disks. Information associated with each storage access request is stored in one of the logs. A cycle of log switching is performed. A write order consistent tracking coordinator coordinates the log switching with agents at the servers to maintain request ordering. Replication coordinators coordinate the application of the switched-out log files from primary storage to replica storage, creating a write-order consistent point on the replica side matching the primary side, and providing for failure resiliency regarding transfer of the logs. The replication logs may be received individually on the replica side from the servers on the primary side to enable highly scalable parallel/simultaneous transfers of the logs.

Abstract: Methods and systems are disclosed in which inherited activation opens a secure communication path from the host operating system (OS) to the guest (virtual machine) OS. The license state of the software on the host is passed through this channel, and software installed in the guest uses this information to inform its own product activation process. The virtualized (guest) software may then activate without any outside communication when the license requirements for the host are met.

Abstract: Methods and systems are disclosed in which inherited activation opens a secure communication path from the host operating system (OS) to the guest (virtual machine) OS. The license state of the software on the host is passed through this channel, and software installed in the guest uses this information to inform its own product activation process. The virtualized (guest) software may then activate without any outside communication when the license requirements for the host are met.

Abstract: In some embodiments, an activation object used to activate a software product is stored in a directory service. The activation object may, for example, comprise a proof of purchase token and/or information about the directory service, and may be communicated from the directory service to a client computer after the directory service authenticates a request from a client computer for access to the activation object. In some embodiments, a directory service is interrogated for an activation object used to activate software on a client computer. A client computer may, for example, receive an activation object from the interrogated directory service, and use the received activation object to activate a software product on the client computer. In some embodiments, a non-transitory computer-readable medium has instructions stored thereon that, when executed by a computer, cause the computer to interrogate a directory service for an activation object used to activate software on the computer.

Abstract: Systems and methods are provided for activation of software that uses digital licenses. In some embodiments, a software vendor may securely deliver at least one digital proof-of-purchase to an OEM (e.g., to avoid piracy of software licenses). The OEM may install an associated software copy on a computer system, and store the at least one digital proof-of-purchase on it. The OEM may communicate the proof(s)-of-purchase stored on the computer system and its system identifier to the software vendor. A user of the computer system may attempt to activate the OEM pre-installed software by sending an activation request to a software vendor, who may verify whether or not the digital proof-of-purchase and system identifier in the activation request match those previously reported by the OEM, and may either grant or deny the activation request.

Abstract: Systems and methods are provided for activation of software that uses digital licenses. In some embodiments, a software vendor may securely deliver at least one digital proof-of-purchase to an OEM (e.g., to avoid piracy of software licenses). The OEM may install an associated software copy on a computer system, and store the at least one digital proof-of-purchase on it. The OEM may communicate the proof(s)-of-purchase stored on the computer system and its system identifier to the software vendor. A user of the computer system may attempt to activate the OEM pre-installed software by sending an activation request to a software vendor, who may verify whether or not the digital proof-of-purchase and system identifier in the activation request match those previously reported by the OEM, and may either grant or deny the activation request.

Abstract: In some embodiments, an activation object used to activate a software product is stored in a directory service. The activation object may, for example, comprise a proof of purchase token and/or information about the directory service, and may be communicated from the directory service to a client computer after the directory service authenticates a request from a client computer for access to the activation object. In some embodiments, a directory service is interrogated for an activation object used to activate software on a client computer. A client computer may, for example, receive an activation object from the interrogated directory service, and use the received activation to object to activate a software product on the client computer. In some embodiments, a non-transitory computer-readable medium has instructions stored thereon that, when executed by a computer, cause the computer to interrogate a directory service for an activation object used to activate software on the computer.

Abstract: Methods and systems are disclosed in which inherited activation opens a secure communication path from the host operating system (OS) to the guest (virtual machine) OS. The license state of the software on the host is passed through this channel, and software installed in the guest uses this information to inform its own product activation process. The virtualized (guest) software may then activate without any outside communication when the license requirements for the host are met.

Abstract: Applications or operating system components requiring a SKU, or other indicator of an operating system, make a call to an API. The calling application passes an indicator of the most current version of an operating system known at the time of the application creation as an argument. This argument may be an indictor of the operating system version, build number, and service pack version, for example. The called API may reference a table of operating system SKUs with the indicator of the most current operating system known to the calling application. If found, the API returns the corresponding SKU to the calling application. If not found, the API returns the SKU corresponding to the closest sequential match to the passed in indicator. The calling application may then execute believing it is using the operating system corresponding to the returned SKU.

Abstract: A cache is provided that stores licensing policies and information for components. The cache is available early in the boot cycle, such as during initialization and startup of the operating system, for use by the kernel and early boot components. Kernel and early boot components can then call a kernel application programming interface (API) to query the policy values. The policy values are read from a registry value into memory very early in the boot sequence. Using the kernel cache, the system may be started with proper licensable limits.

Abstract: Applications or operating system components requiring a SKU, or other indicator of an operating system, make a call to an API. The calling application passes an indicator of the most current version of an operating system known at the time of the application creation as an argument. This argument may be an indictor of the operating system version, build number, and service pack version, for example. The called API may reference a table of operating system SKUs with the indicator of the most current operating system known to the calling application. If found, the API returns the corresponding SKU to the calling application. If not found, the API returns the SKU corresponding to the closest sequential match to the passed in indicator. The calling application may then execute believing it is using the operating system corresponding to the returned SKU.

Abstract: Storage access requests are received from one or more applications. Multiple servers update multiple virtual disks as directed by the storage access requests. The virtual disks store data that is write order dependent across the virtual disks. Logs are associated with the virtual disks. Information associated with each storage access request is stored in one of the logs. A cycle of log switching is performed. A write order consistent tracking coordinator coordinates the log switching with agents at the servers to maintain request ordering. Replication coordinators coordinate the application of the switched-out log files from primary storage to replica storage, creating a write-order consistent point on the replica side matching the primary side, and providing for failure resiliency regarding transfer of the logs. The replication logs may be received individually on the replica side from the servers on the primary side to enable highly scalable parallel/simultaneous transfers of the logs.