User Profile
SPatkar_Blogs
Copper Contributor
Joined 6 months ago
User Widgets
Recent Discussions
Renew RDS CAL Licenses for 120 Days
Important Note Before proceeding, please be aware that this method is a temporary workaround and should not replace proper license management practices. Always ensure that you comply with Microsoft's licensing terms and conditions. Prerequisites Administrator access to the RDS server. A backup of the registry (to revert any changes if needed). Familiarity with Windows Registry Editor. Step-by-Step Guide Step 1: Backup the Registry Press Win + R, type regedit, and press Enter to open the Registry Editor. In the Registry Editor, click on File and then Export. Choose a location to save the backup and provide a name for the backup file. Click Save to create the backup. Step 2: Stop the Remote Desktop Licensing Service Press Win + R, type services.msc, and press Enter to open the Services Manager. Scroll down to find Remote Desktop Licensing or Remote Desktop Services. Right-click on the service and select Stop. Step 3: Grant your ID access to GracePeriod and delete the Key from your registry editor: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod Step 4: Restart the Remote Desktop Licensing Service Go back to the Services Manager. Right-click on Remote Desktop Licensing or Remote Desktop Services. Select Start to restart the service. Step 5: Reboot the Server Save any open files and close all applications. Reboot the server to apply the changes. Step 6: Verify the Renewal After the server restarts, open a command prompt as an administrator. Type the following command and press Enter: wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TerminalServiceSetting WHERE (__CLASS !="") CALL GetGracePeriodDays Conclusion Renewing RDS CAL licences by deleting registry entries is a temporary solution that can help extend your licencing period for 120 days. Remember, this is not a permanent fix, and you should plan to acquire proper licenses to ensure compliance with Microsoft's licensing policies. Regularly check your licensing status and renew your CALs accordingly to avoid any disruptions in your Remote Desktop Services. If you have any questions or need further assistance, please feel free to reach out. Stay compliant and ensure your business operations continue smoothly! -- Santosh Patkar1.3KViews0likes0CommentsConfiguring a Disaster Recovery Solution for Azure Service Bus with Basic Tier
Introduction Disaster recovery (DR) is crucial for ensuring business continuity and minimizing downtime. While the Azure Service Bus Basic tier doesn't support advanced Geo-disaster recovery (Geo-DR) or Geo-Replication(Public Preview) features like the Premium tiers, you can still implement a custom DR strategy. This guide will walk you through setting up a disaster recovery solution for Azure Service Bus using the Basic tier. Prerequisites Before starting, make sure you have: An Azure subscription. Two Azure Service Bus namespaces (one primary and one secondary) in different regions. Access to the Azure portal. Familiarity with Azure CLI or PowerShell for automation purposes. Step-by-Step Guide Step 1: Create Primary and Secondary Namespaces Create the Primary Namespace: Go to the Azure portal. Search for "Service Bus" and select "Create Service Bus namespace". Enter a name for the namespace (e.g., primary-ns-basic), choose the Basic tier, and select the primary region. Click "Review + create" and then "Create". Create the Secondary Namespace: Repeat the steps to create a secondary namespace in a different region (e.g., secondary-ns-basic). Step 2: Synchronise Messages Between Namespaces Since the Basic tier does not support Geo-DR, you'll need to manually synchronise messages between the primary and secondary namespaces. This can be achieved through custom code or third-party tools. Implement Message Synchronisation: Create an application that listens to messages on the primary namespace and republishes them to the secondary namespace. Use Azure Functions or a similar service to trigger this application whenever a new message arrives. Ensure the application handles any potential issues, such as message duplication or order. Sample Synchronization Code (Azure Functions with C#): using System; using System.Text; using System.Threading.Tasks; using Microsoft.Azure.ServiceBus; using Microsoft.Azure.WebJobs; using Microsoft.Extensions.Logging; public static class MessageSynchroniser { private static string primaryConnectionString = "<PrimaryNamespaceConnectionString>"; private static string secondaryConnectionString = "<SecondaryNamespaceConnectionString>"; private static string queueName = "<QueueName>"; private static IQueueClient secondaryQueueClient; [FunctionName("MessageSynchroniser")] public static async Task Run([ServiceBusTrigger(queueName, Connection = "primaryConnectionString")] Message message, ILogger log) { secondaryQueueClient = new QueueClient(secondaryConnectionString, queueName); try { var secondaryMessage = new Message(Encoding.UTF8.GetBytes(message.Body)) { ContentType = message.ContentType, Label = message.Label, MessageId = message.MessageId, CorrelationId = message.CorrelationId, UserProperties = message.UserProperties }; await secondaryQueueClient.SendAsync(secondaryMessage); log.LogInformation($"Message synchronised to secondary namespace: {message.MessageId}"); } catch (Exception ex) { log.LogError($"Error synchronising message: {ex.Message}"); } finally { await secondaryQueueClient.CloseAsync(); } } } Step 3: Failover Procedure In the event of a disaster, you will need to manually failover to the secondary namespace. Update Connection Strings: Modify your application configuration to point to the secondary namespace's connection string. Restart your applications to ensure they connect to the secondary namespace. Communicate the Change: Notify your team and stakeholders about the failover. Monitor the secondary namespace to ensure it is handling the load appropriately. Step 4: Failback to Primary Namespace Once the primary region is operational again, you can switch back to the primary namespace. Resynchronise Messages: Ensure that any messages in the secondary namespace are synchronised back to the primary namespace. Use the same message synchronisation approach as before but in reverse. Update Connection Strings: Change your application configuration back to the primary namespace's connection string. Restart your applications to point back to the primary namespace. Best Practices Regular Testing: Periodically test your disaster recovery plan to ensure it works as expected. Automation: Automate as much of the DR process as possible to minimise downtime and human error. Monitoring: Set up monitoring and alerts for both primary and secondary namespaces to detect issues early. Documentation: Keep detailed documentation of your DR processes and ensure your team is familiar with them. Conclusion While the Azure Service Bus Basic tier lacks built-in Geo-DR capabilities, you can still create a robust disaster recovery solution through custom synchronization and failover procedures. By following the steps outlined in this guide, you can ensure your messaging infrastructure is resilient and prepared for any disruptions. Regular testing and monitoring will help maintain the effectiveness of your DR strategy. Feel free to reach out if you have any questions or need further assistance. Happy configuring! -- Santosh Patkar760Views1like3Comments
Groups
Recent Blog Articles
No content to show