Active Directory: Logon script not working on user device when its inside (FQDN domain name\NETLOGON folder)

Hi everyone, hope you guys are taking care of yourself. Meanwhile, I’m not really in a great mood today, as there were some conflicts at work, well that’s what happen when you got to deal with humans right? Pretty normal, I guess.

Anyway, I still wanted to write a post about the experience I had today, and it did take me sometime to realized that there was something in between the user’s laptops/desktop and Active Directory that was causing the script unable to ran. Anyway, the environment did not have anyone who is technical but is still not easy to troubleshoot a problem when non-technical users only give you less than an hour to find out what is the problem. Luckily, I did meet someone who knows well enough the infrastructure of the environment….

I understand that the politics are so strong between parent companies and branches, but we all have a life to move on, so politics are just excuses to delay tasks or projects to complete. We are all being paid to do tasks, not to spend 8 working hours to gossip and drill down other’s conflicts.

So, enough of chit chat corporate news.

I realized that deploying logon batch file script via Group Policy Object wasn’t working (The script is located the SYSLOG\LOGON folder and FQDN domain name\NETLOGON folder), same goes with AD’s user object’s profile > Logon Script (The batch script is located in the FQDN domain name\NETLOGON folder) and using the Driver mapping feature inside GPO too.

I thought at first it could be my scripting issue but somehow double clicking the batch file script directly onto the user’s device it works. So, I started to think what could be in between the user’s device and active directory. Is it firewall? Is it Microsoft Defender? After clicking the user’s device network settings and realized they have Zscaler product installed.

Zscaler Proxy, where there were policy preventing any remote script running on user’s device. This logon script was to map share drive automatically on the user’s device. During their first practice of how to map drive was to manually map them on their own.

Well, Zscaler was beyond my scope. I don’t have the rights to request the environment to whitelist a script. I can only find out and advise them whether they still want it.

In the end, they told me to just leave the script as a backup for the user.

If you try to search for an answer, there won’t have any on the internet. It was all based on your troubleshooting skillset.

Exchange Migration: Outlook kept prompting for password after migration

Hi guys and girls, hope you are doing well, as the pandemic is still on-going, hope that you guys are keeping cleanliness and safety first.

Today’s topic is about exchange migration of mailboxes from on-premises to Office 365. This issue is where the legacy windows client or legacy office apps has issue with their outlook applications keeps prompting for credentials and showing disconnection. The issue also do happen to Windows 10 machines but not as aggressive as the Windows 7 machines.

This environment has the following items,

  1. Exchange server: 1 unit, version 2013, CU23 (latest)
  2. Windows client: Combination of Windows 7 and Windows 10
  3. Office applications: Combination of 2013, 2016, 2019 and Microsoft 365 apps for business in both windows 7 and windows 10 categories
  4. Migration method: Remote move migration
  5. Hybrid establishment: Yes
  6. Microsoft 365 license: Business standard/basic

As we all know that the major pre-requisites must met before starting the hybrid and perform migration.

We notice intermittent connections while running the Wireshark on Windows 7 with M365 business apps, while trying to login using the migrated account credential on an Outlook app. We ran a re-creation of the outlook profile and the prompt for credential has stops. This is definitely not the right solution. Solutions is dependent with what caused the issue.

At first we suspected something got to do whitelisting on the network layer but we had confirmed that the whitelisting are correctly configured. Next, we suspected something go to do with compatibility on windows with/or office apps version. This is not a very good idea. After quick research, I came about modern authentication could be the caused, and there where I had an idea on suggesting to turn off the security default in Azure portal and then turn off the modern authentication in Office 3655 tenant. After 10 to 15 mins, the intermittent connections no longer shows up on the Wireshark.

Modern authentication is enabled by default for every new Office 365 tenants, so please be aware if your environment has legacy windows client running or legacy office applications, do consider to turn them off first before proceeding to deploy Microsoft 365 apps.

Azure portal > Azure AD > Properties > Manage security defaults
Office 365 admin center > Settings > Org Settings > modern authentication

Modern authentication was the one the interfered with the machines and it kept challenging the users to key in credentials due to the compatibility was not met. Once the modern authentication is turn off, the environment now is running basic authentication.

References:

Intune Autopilot: Troubleshoot RDP access prompt

So I am testing Autopilot in my lab environment, consist a Hyper-V with its Virtual Machines. Well I am doing a manual registration, so how do I export the device information that is required my VM to be register for Autopilot?

I already have a VM running Windows 10 Pro, and I ran this script to export and automatic import the device information to be register into autopilot. However, I wasn’t running the script before Out-of-the-box-experience (OOBE) happen, so to make Autopilot work on my VM, I had to reset my VM.

Once the VM has reset,  it ask for region, language of my keyboard and next it shows a welcome page with the Display name and the company name. So I key in the email address and password of the user and also setup the PIN. However, I just notice that I set this user with the Standard permission only. Thus, the administrator account is disabled and I keep getting the RDP permission error prompt due to the user account is not in the RDP group in the VM.

Example of the prompt;

To sign in remotely, you need the right to sign in through Remote Desktop Services. By default, members of the Remote Desktop Users group have this right. If the group you’re in doesn’t have this right, or if the right has been removed from the Remote Desktop Users group, you need to be granted the right manually.

050317_1039_Tosigninrem1

How I troubleshoot this;

  1. Is to run MMC as administrator > File > Add/Remove Snap-in
    • Capture
  2. Key in your Office 365 admin account (an account with permission that can manage device)
  3. Select Local Users and Groups > Add
    • Capture
  4. Select Local computer > Finish > Ok
  5. Expand the local users and groups > Users > Right click Administrator  > Uncheck Account is disabled
    • Capture
    • Capture
  6. Reset the local Administrator password too
  7. Select Groups > Right click on the remote desktop users > Add > Authenticated users > Ok
    • Capture
  8. Close MMC
  9. Sign out and Sign in again

 

These steps should help you from getting the prompt again.

Please take note that I am doing this in Lab environment. In production, by right not to enabled administrator account and not to do any changes to the local users and groups. 

Windows 10: How to setup Windows Hello?

This blog is based on my experience on how to setup windows hello. I really like to capture every single steps or actions are performed, because it is much easier for me (beginner) and end users to understand.

*Note

Please go through this blog first “https://sabrinaksy.wordpress.com/2017/08/27/ad-gpo-how-to-enable-windows-hello/

Precaution;

Before implementing, please do go through and understand the steps given below. Each steps are given clear elaboration on how to perform it. Skipping a step will causes you confusion.

Here are the steps by steps;

For administrator;

At end user’s computer

  1. Run Command prompt as Administrator at end user’s computer
  2. Type in the following commands;
Gpupdate /force
  1. Close Command prompt, once all policies has updated

OR, At the AD server

  • Open Group Policy Management
  • At the OU where the windows hello GPO is created for
  • Right click on the OU and click on the force gpupdate on all active computers

For end users;

After successfully updated the group policy on the end user side.

  1. Go to > Start
    hello1
  2. Click on the > Setting
    • Then it will direct you to the setting interface;
    • hello2
  1. Click on > Accounts
  2. At the left-side bar
    • Select > Sign-in Options
    • hello3
  3. Scroll down and find PIN
    • Select > Add
    • hello4
  4. After that it will prompt you to enter your computer login password
    • hello5
  5. After successfully authenticate your credential, then enter convenience PIN number
    • hello6.png
  6. After enter the PIN number, your PIN status will change into something like below image;
    • hello7.png
  7. Scroll back up and find ‘Face Recognition’
    • Select > Set up
    • hello8
  8. A ‘Welcome’ interface will appear;
    • Select > Get started
    • hello9
  9. Enter the PIN, that you had set for yourself earlier;
    • hello10.png
  10. After successfully authenticate your PIN number, a face recognition interface will appear;
    • Place your face in-front of the camera where it can detect your face
    • hello11.png
  11. After that a successful interface will appear;
    • Select > Close
    • hello12.png
  1. To give it a try out;
    • Sign out from your computer account and you will see a different interface like the image below;
    • hello13.png