User Profile
SPatkar_Blogs
Copper Contributor
Joined 8 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 Patkar2KViews0likes0CommentsConfiguring 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 Patkar852Views1like3CommentsRe: M365 License Expiration- Enterprise Agreement
BINODMAHARJAN2022 License Expiration and Grace Period: License Expiration: When your Microsoft 365 E1 licenses expire, they enter a grace period rather than being immediately deactivated. During this grace period, users can still access their services, including Exchange Online, but certain limitations apply. Grace Period: Microsoft typically provides a grace period of 30 days after the license expiration date. During this time, users will still be able to access their accounts and services. Access to Services: During the grace period, users will still have access to Exchange Online services. This means that ongoing migrations should not be interrupted immediately when the license shows as expired. Migrations in progress should continue to run until completed as long as they fall within this grace period. Post-Grace Period: Post-Grace Period Actions: After the grace period, licenses enter a disabled state. In this state, users will lose access to services, and migrations in progress may be affected. It is critical to ensure that migrations are completed within this timeframe or to make alternative arrangements. Disabled State: If licenses are not renewed after the grace period, users will no longer be able to access Exchange Online services, which will halt any ongoing migrations. Recommendation: Given your situation, it is essential to ensure that as many migrations as possible are completed within the grace period. If you foresee delays, consider renewing licenses temporarily to cover all users until migrations are fully completed. If you need further assistance or have additional questions, please let me know!940Views0likes0CommentsRe: M365 License Expiration- Enterprise Agreement
When a license is removed/expired from a user, Exchange Online data that is associated with that account is held for 30 days. After the 30-day grace period, the data is deleted and can't be recovered. https://learn.microsoft.com/en-us/microsoft-365/admin/manage/assign-licenses-to-users?view=o365-worldwide#what-happens-to-a-users-data-when-you-remove-their-license1.2KViews1like2CommentsRe: can not delete domain because of user references
Check if any users or groups are having this custom domain. Check if any deleted users are having this custom domain. Check the domain of the GA account which you are logged in with. Ensure that the Global Administrator account is using the initial default domain name (.onmicrosoft.com) such as email address removed for privacy reasons. Sign in with a different Global Administrator account that such as email address removed for privacy reasons or another custom domain name like “fabrikam.com” where the account is email address removed for privacy reasons. If domain deletion fails, ensure that you don’t have: Apps configured on the domain name with the appIdentifierURI Any mail-enabled group referencing the custom domain name More than 1000 references to the domain name The domain to be removed the set as the Primary domain of your organization Also note that the ForceDelete option won't work if the domain uses Federated authentication type. In that case the users/groups on the domain must be renamed or removed using the on-premises Active Directory before reattempting the domain removal. If you find that any of the conditions haven’t been met, manually clean up the references, and try to delete the domain again. https://learn.microsoft.com/en-us/powershell/module/azuread/remove-azureaddomain?view=azureadps-2.0 Try this powershell with -Force command.651Views0likes1CommentRe: Entra ID only accounts with Entra Domain Services, and RDS - what CAL?
Setting up RDS in a scenario where you only have Entra ID (Azure AD) and not a traditional Active Directory can indeed be challenging due to the limitations around user CALs and trust relationships. You can try this method and check if this works for your scenario: https://learn.microsoft.com/en-us/azure/virtual-desktop/azure-ad-joined-session-hosts517Views0likes1Comment
Groups
Recent Blog Articles
No content to show