I’d been struggling with an additional keyboard language on my Microsoft Surface Pro 7 since the last update to 20H2: usually, I would only add two (2) different language – English-US & Chinese-PRC for my daily use; however, there’s an “alienated” English-UK that keeps appearing at the language bar:

When accessing from Settings > Time & Language, the Keyboard shows English (United Kingdom)

When trying to change the default language, only a single selection “Use language list (recommended)” is available:

So what’s annoying? Whenever trying to type certain alphabets – it tends to convert into umlaut (e.g., Ü); so now – how to get rid of them? Most articles basically leads me to add English (United Kingdom) and removing it from the Preferred languages or making changes to the registry, so far none of them works for it till I came across this method:

  1. Go to Settings > Time & Language > Language
  2. Under Preferred languages, click on “+” Add a language
  3. Located English (United Kingdom)

  4. Uncheck all of the options and click on Install

  5. Once done, run PowerShell as Administrator and run the following commands:
Get-WinUserLanguageList
$LangList = Get-WinUserLanguageList
$MarkedLang = $LangList | where LanguageTag -eq en-GB
$LangList.Remove($MarkedLang)
Set-WinUserLanguageList $LangList –Force

Now, I’ve gotten back a clean language bar on my Windows 10 🙂

Reference: Can’t remove English UK keyboard after windows update

On my previous article, I’ve demonstrated on how to manually (forcefully) upgrade the Teams Room System App. As you must at least be on version 4.5.35.0 to proceed have this feature working on your Teams Room System

  1. From the MTR Console, go to Settings > Meetings and enable Cisco Webex. Click on Save and Exit and the device will automatically reboot by itself.

2. Next, launch Microsoft Exchange Online Powershell Module and execute this command: Set-CalendarProcessing MeetingRoom@domain.com -ProcessExternalMeetingMessages $True -DeleteComments $False -DeleteSubject $False (Reference: Enable Teams Room devices to join third-party meetings)

3. If you have Office 365 E5 or Microsoft Advance Threat Protection enabled within the tenant, it is recommended to create an URL rewrite exception policy. Login to Office 365 Security & Compliance Center

4. Click on Threat Management > Policy > ATP Safe Links

5. Click on the + sign

6. Configure the rule as follow:
– Name: URL Rewrite Exception Rule
– Select the action for unknown potentially malicious URLs in messages – ON
– Under the Do not rewrite the following URLs, key in the entry *.webex.com*
– IMPORTANT: Move the rule to the top most to make sure other rules doesn’t override it
(Reference: Set Up a Custom Do Not Rewrite URLs list using ATP Safe Links)

7. Now Login to your Cisco WebEx account or click here to register for a free account

8. Click on Schedule

9. Make sure to invite the Room (Resource) Mailbox at the Attendees column

10. Once the booking is successfully accepted by the Room Mailbox, you should get the similar launcher within the MTR – a Cisco Webex icon with a Join button activated (Cool uh?)

11. When it is about time to join the meeting, notice that the Join button is now “lighted up”

Simply click on the Join button and you’re good to go for your meetings!

To my readers whom have been visiting / visited my blog: Yes, is been a while since I last posted any articles or blogs due to my new founding company – UniQ Consulting. It is not an easy journey but it has been exciting and fun (so far). Still pretty much focusing on Microsoft 365 Cloud solution and thanks to my contact in Lenovo, I’d been given a chance and opportunity to try out Lenovo Microsoft Teams Room System solution – the ThinkSmart Hub 500 for Microsoft Teams Room System and ThinkSmart View for Microsoft Teams. However, in this article, I’m going to dive straight away into how to manually (aka forcefully) update the MTR to the latest version.

Recently, my Lenovo contact had boast to me that Microsoft had just released the latest version of 4.5.35.0 – 23rd July 2020 awhich comes with a long waited feature – Joining a Cisco Webex Meeting using the direct guest join function, and he had managed to get it installed on his unit. As most of you guys may already know, Microsoft Teams Room System App basically performs a daily updates around 2.00AM, which can be triggered through the Task Scheduler. As I couldn’t contain this excitement, I’d repeatedly trigger the update, hoping that the updated bits could be downloaded and installed onto my unit as well – unfortunately after waiting for a night, the version remained the same. Till I stumbled across the article from Microsoft Docs here

To perform the manual update:

  1. Download the latest MTR version 4.5.35.0 HERE and run the installer within the MTR. By default, the installer will extract all content into this default path C:\Program Files (x86)\Skype Room System Deployment Kit

2. Launch PowerShell with Administrator privileges

3. Run this command Add-AppxPackage -ForceApplicationShutdown -Path ‘C:\Program Files (x86)\Skype Room System Deployment Kit\$oem$\$1\Rigel\x64\Ship\AppPackages\*\*.appx’ -DependencyPath (Get-ChildItem ‘C:\Program Files (x86)\Skype Room System Deployment Kit\$oem$\$1\Rigel\x64\Ship\AppPackages\*\Dependencies\x64\*.appx’ | Foreach-Object {$_.FullName})

4. Reboot

5. Once the device comes back online, go to settings and verify the App Version

In my next article – I’ll be showing on how to enable Cisco Webex on a Microsoft Teams Room System 😉

[Update 1-March 2022] Microsoft has released a PowerShell to automate this process entirely, which you can find it from here (in sequence):
Switching to Admin Mode and back when the Microsoft Teams Rooms app crashes
Manually update a Microsoft Teams Rooms device

My first post in 2018! OK – I’m sorry for not being writing for a while as work has been pilling up on me and I plan to get my engine restarted, with a short article which probably *most* of you may already experience this or done it before.

In a very recent case, I’d switch my profile from a cache mode to Online mode (couldn’t recall the exact reason but likely was due to some testing that I was carrying out for my customer) and did a quick restart on my Outlook.

After loading back, I notice my Outlook as duplicated calendar entries, which cannot be removed

To resolve this:

  1. Close Outlook (and other supporting Applications like Skype for Business, Microsoft Teams & etc).
  2. Click Start > Run > type outlook /resetnavpane
  3. Upon launching, you should get a much cleaner (single & required only) entries

Hope this helps for those whom are stumbling for a resolution. Stay tune for more updates and blogs!

As Microsoft Office 365 (Cloud) continues to grow and expand, its workload continues to be adopted as well. Those were the days (or maybe till now), where emails (Exchange) are treated as the *only* and primary communication tool, now, more and more organizations are also adopting to Real-Time Communication (Lync, Skype for Business) as part of their operation workforce as well.

In most of my engagements, most organizations only has Lync/Skype for Business Server On-Premise without enterprise voice enabled, and most of them opt to ‘move’ directly to the cloud without any co-existence or migration from the On-Premise servers. Hence, you’ll notice that users whom has their account enabled on Lync/Skype for Business Server 2015 will not appear at the Admin Center, even though the Skype for Business Online Cloud has been enabled.

A workaround for this is to remove any existing Lync/Skype for Business entries from the user object:

Disable the user from any existing Lync / Skype for Business Pool Server. Make sure to click on Commit to save the changes

 

 

 

 

 

 

 

Next, launch the adsiedit console. Locate the user and clear the following entries:

  • msRTCSIP-DeploymentLocater
  • msRTCSIP-FederationEnabled
  • msRTCSIP-InternetAccessEnabled
  • msRTCSIP-OptionFlags
  • msRTCSIP-PrimaryHomeServer
  • msRTCSIP-PrimaryUseraddress
  • msRTCSIP-UserEnabled
  • msRTCSIP-UserPolicies
  • msRTCSIP-UserRoutingGroupId

 

 

 

 

 

 

 

*Should you encounter any errors during the clearing process. Close the object property window and re-open it and continue where you’ve left off

Once the attributes are cleared, make sure the Active Directory are fully replicated and initial a Delta synchronization from the Azure AD Connect. The user should now appear at your Admin Center and would be able to login to the Office 365 Skype for Business Online Services!

With Cloud on the ‘loose’, Microsoft has offered a very flexible platform which allows organizations to easily subscribe for trials or even register for a tenant on the fly. However, without a proper clean-up would create additional hassles and steps, especially if the Global Admin is no longer around or the login credential has been misplace – and this what happened to me in a recent Office 365 engagement.

In this implementation, we were supposed to activate the actual domain (Example: mydomain.com) to a new Ofifce 365 tenant. However, when attempting to associate the corporate domain into the Office 365 tenant, the portal had detected that our domain has been used and activated with another tenant – for Microsoft Power BI purposes, to make things complicated, nobody knows whom own the other domain.

To ‘regain control’ of the corporate domain, we’d to create an automated generated TXT record to proof that we’re the actual and will be the Global Admin taking over the Power BI tenant. After which we’d to remove the corporate domain that has been configured with the Power BI tenant but were thrown with an error message:

Dependencies on domain. To remove this domain, you’ll have to remove the following dependencies first.

Remove_Domain01

When expand, the alias and Skype addresses indicate the users which has been assigned within the tenant, although there wasn’t any Exchange Online and Skype for Business Online licenses are available. In the end, we’d to use PowerShell to remove the corporate domain:

  • Connect-MsolService
  • Remove-MsolDomain -DomainName $mydomain.com -Force

Refresh the Admin portal and we manage to remove the corporate domain that was initially assigned to the Power BI tenant and ‘migrated’ it to the actual Office 365 domain.

This is a continuity from my previous post on sharing my experience in dealing with Web Proxy and Office 365. You may browse through or select the following topics:

  • Office 365 & Web Proxy Part 1 – Conceptual Design & Preparation
  • Office 365 & Web Proxy Part 2 – Prepare Symantec .Cloud Web Gateway for Office 365
  • Office 365 & Web Proxy Part 3 – Setting up the Symantec Client Side Proxy & Cloud Web Gateway
  • Office 365 & Web Proxy Part 4 – Setting up Firewall for Office 365
  • Office 365 & Web Proxy Part 5 – Troubleshoot Skype for Business Online with Cloud Web Proxy

In this chapter, these are the components that are made up to make the solution work:

  1. Active Directory Users & Security Groups
  2. Symantec Directory Synchronization Tool (SCHEMUS)
  3. Active Directory Group Policy Object (GPO)

The key essence in this deployment is identifying the types of URLs or Web Categories that the users would be allow and prohibited to access, so before we begin the building the web policies, it is extremely crucial to identify the groups of users and types of materials (URLs) that they needed to access to ensure both productivity and restrictions are applied according to the corporate policies.

To start off, I’ve created the security groups, using the this format: Web-XYZ, where Web indicates for Web Proxy while XYZ stands for the type of access. For example: Web-YouTube, where users in this group are allowed to access to YouTube. Placed all of these groups into a dedicate OU which we’ll be using Symantec Synchronization Tool (SCHEMUS) to synchronous to the Symantec .Cloud. For general guideline, you may structure / plan the Security Groups in this manner:

  • Web-YouTube
  • Web-SocialMedia
  • Web-PublicWebMail
  • Web-BasicWeb

Once the security groups has been created, install SCHEMUS onto a designated system, SCHEMUS doesn’t required much resources so you may collocate with the Azure AD Connect which performs the same synchronization activity the cloud.

Configuring SCHEMUS very much similar to Azure AD Connect – select the OU Container (best practices) which holds all of your users and security groups:

1. Give a Name to the Synchronization (e.g. Sync Web) and select Users at the synchronization type column

schemus01

2. Select Microsoft Active Directory as the Source Type

schemus02

3. Fill-up the hostname of your Domain Controller along with your Domain Admin’s Username & Password

schemus03

4. Select the OU that you’ve store all of your corporate Users

schemus04

5. At the next screen, SCHEMUS will attempt to query a list of sample users from the last selection that you’ve made. If you’ve confirm that the queried objects are correct, move on to the next screen

6. Select Symantec .Cloud at the Repository Type

schemus06

7. During the initial launch after installing SCHEMUS, you’ll be prompt for Symantec .Cloud user credentials to activate the application. So can continue with the wizard by leaving this option on its default configuration.

schemus07

8. If you need to omit any objects in this synchronization, key in the filters or leave the values blank (default)

schemus08

9. Leave the limits to its default unless you’ve a good reason to limit the number of users that needs to be synchronized

schemus09

10. I would highly recommend that you configure the notifications for any synchronization failures as the synchronization tasks will be perform based on scheduled – which is similar to Azure AD Connect. Key in your SMTP relay server (I’m assuming that no active mail server are still available as we’re moving to Office 365 – duh!)

schemus10

11. On the final configuration screen of SCHEMUS, click on Verify to make sure all of the configuration are working as expected

schemus11

If everything is successful, you should get the (similar) screen as mine

schemus14

12. Schedule the synchronization tasks based on your desired time

schemus12

13. Click on Save to complete the synchronization for Users. Repeat Step 1 – 13 for Groups and Mail (if any)

14. Click on Update at the left of the SCHEMUS window screen and you should be able to see the list of users and groups being synchronized to the Symantec .Cloud

Next, we move on to configuring the Symantec .Cloud CA Root certificate, this is to allow HTTPS inspection when users attempting to browse to any HTTP Secure Sites. Grab the file from your ClientNet portal > Tools > Downloads

Symantec Web Security Cloud Root CA

After downloading it, publish it to all domain member workstations, desktops and / or laptops via the Active Directory GPO:

Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities

Import the downloaded Symantec Web Security .Cloud Root CA and all domain members machines will automatically download it to the local certificate store, this would allow all major browsers – Internet Explorer, Google Chrome & Microsoft Edge (Except FireFox) to automatically recognizes and accepts the certificate when the HTTPS inspection triggers at the Cloud level. I would recommend to link the Policy at the designated OU which you’ve stored all your client machines; if you’d been leaving the machines at the default container – Computers, update the configuration using the Default Domain Policy GPO.

symantec_rootca_gpo

Now that the core elements are in-place, we’ll now proceed to the next topic on configuring the Client Side Proxy (CSP) and setting up rules and policies at Symantec .Cloud Services.

As Office 365 (Cloud) Solution & Services are getting very common to most organization, restricting and controlling of bandwidth to ensure users’ experience are not impacted – as compared to the traditional method where internal communications are deemed to be seamless, where connectivity are between 100 Mbps to 1 Gbps.

This time around, I’ll be sharing a recent implementation that involves with Office 365 and Symantec Cloud Web Proxy:

In this engagement, the client has subscribe onto a mixture of Office 365 Business Essential, Exchange Online Plan 1 and Exchange Online Kiosk, with a total of 600 users within the organization. The plan was to migrate the existing on-premise Exchange Server 2007 to Exchange Online, activate all workloads and subsequently enforce the web browsing usage – this is to ensure the users’ experience while using the Cloud are not impacted by non-productive web browsing during office hours. (e.g. Audio & Video Streaming). Hence, two (2) elements are involve – The firewall and cloud-based web proxy.

To get things started, the following components has been deployed in the infrastructure:

  1. Active Directory – GPOs are highly used for this deployment
  2. WPAD script which has been customized and published onto a Windows Server 2012 R2 Internet Information Services (IIS)
  3. DHCP with option 252 enabled and mapped to the Web Server
  4. Symantec .Cloud Web Gateway subscription
  5. Symantec Directory Synchronization Tool (SCHEMUS)
  6. Symantec Client Side Proxy with customized configuration with the bypass URLs. The Symantec CSP underlying core runs on SQUID Services where most of the configuration are highly customizable
  7. Fortinet Firewall

Working mechanism:

office-365-symantec-cloud-web-proxy_01

  1. The DHCP Servers distributes the WPAD script as part of leasing IP addresses to the endpoints (during boot-up). The browsers will then make HTTP / HTTPS requests either directly to the Server Farm (Internal Web Servers) or through the Symantec Client Side Proxy (CSP).
  2. Based on the configuration and policies (ACL) within the Symantec SCP, the browsers either gets to entirely bypass without any authentication OR basically passes through the Symantec .Cloud Web Gateway for web filtering.
  3. In this scenario, we’ve set ALL Office 365 URLs and a set of the organization’s permitted web sites (e.g. Banking Sites) where web traffics will basically bypass the Symantec .Cloud Web Gateway filtering policies while the rest will be tunneled to the Cloud Gateway before reaching to the Internet

Before starting Part 2, is it important to identify the list of frequent URLs with their associated user groups to it, types of non-browser based applications and services, IP subnets and Web Browsers used within the organization; so far, Internet Explorer, Microsoft Edge, Google Chrome & Safari doesn’t impose any compatibility issues with the above infrastructure, however Mozilla Firefox requires attention and additional steps in order to get the browser working with the Cloud Proxy.

Finally, a lighter version of the Persistent Chat (within Skype for Business Server / Lync Server) is launched which can be easily activated with a simple flip of a switch. Microsoft Teams was launched earlier this month as part of the Office 365 subscription – which is available on Business Essentials, Business Premium, Enterprise E1, E3 and E5. (Reference: Introducing Microsoft Teams)

If you happen to be on either of the subscribed plan(s) mentioned earlier, login to your Office 365 Admin Center and follow the step-by-step guide:

Admin

  1. At the Admin Center, Select on Apps > Microsoft Team
    MS-Teams01
  2. “Flip” on the ON switch at the top right and click on Save
    MS-Teams02

 

So when that’s done, download the Microsoft Teams client App here and you can start creating your own Virtual Groups / Teams and start collaborating!

MS-Teams03

Hello and Happy Monday! Yes, I know and I’m sorry that I’d left my blog “in the cold” as life-work and business has took away most of my time since I’ve started my own (Woo-Hoo!). In this article, I’m about to share about another Cloud platform which involves integration with Microsoft Office 365.

As the industry “all” moves to the cloud, the dependencies of deploying and configuring Cloud platforms gradually increases as well.

Recently, I was involved with an Office 365 with Symantec.Cloud integrated (Mail & Web) and we’d to setup a Schemus Server (similar to Microsoft’s Azure AD Connect) which synchronizes the Active Directory’s Users and Objects to Symantec.Cloud platform. Activating the tenant was pretty straight forward as we already had the tenant ready during the evaluation stage (Proof-of-Concept), next thing is to configure Schemus.

While trying to establish the relationship between the Symantec.Cloud with Schemus, the following error message was presented on the setup window:

Symantec.Cloud_SchemusError

 

 

 

 

 

Can’t access the Symantec.Cloud service. There was a problem communicating with the Symantec.Cloud service server: WS Security The message has expired (WSSecurityEngine: Invalid timestamp The security semantics of the message have expired)

To resolve this issue, make sure the following entries are in-place:

  1. If you’ve recently changes your password for Symantec.Cloud service, update your most recent password at Schemus Configuration OR at the Schemus Windows, click on Edit > Settings > Symantec.Cloud and modify password field
  2. Make sure that the specified URL is accessible and not filtered/blocked by the Firewall
  3. System Time is the same as the Internet time

Symantec_SchemusUpdate

 

 

 

 

 

We ran into the issue on item #3 and what we’d to do was just simply modify the system clock and click on Apply. Close the Schemus and re-launch the settings window and Walla! the problem went away. Based on Symantec Technical Support, updating the system clock to establish the communication with Symantec.Cloud is only one-time off, so for those organizations whom aren’t following the Internet time, the Schemus server would be able to resync its time with either the Active Directory or NTP Server.

MVP Logo