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.
Sabrina Kay's Blog 
It’s sad to hear that you had a grueling day (especially when corporate politics are involved), however you managed to find out the root cause, congratulations for that.
I would like to suggest you a better option to map network shares to drive letters and let go the scripting method for ever, the feature is built in Group Policy Preferences node (you will do it for a User targeted policy) and will save you a lot of time and grief in contrast to the scripted solution.
I hope this helps you with present and future implementations.
Kind regards
LikeLike
Hi George, thanks for the comfort words. Yes I forgot to mention that doesn’t work too. Is out of my scope to bother to investigate Zscaler though. Not worth my time.
LikeLiked by 1 person
If they’re blocking Group Policy application on Endpoints, then they must fix it. It’s not your cup of tea, as you said.
LikeLike
I don’t think is not my cup of tea. I just follow my scope of work. Get paid for what I’m doing. Anything extra got to be ad-hoc charges. haha. Sometime just got to act dumb for something that I know.
LikeLike
Well if the phrase was misunderstood, it means that it is not your responsibility to manage the Zscaler’s exceptions.
LikeLiked by 1 person
It seems that these products are functioning as intended. However, it’s worth noting that Active Directory’s implicit trust makes it a prime target for cyber attackers. As a security community, it’s essential that we adopt a zero-trust approach. Running unsigned scripts on a domain controller without proper verification isn’t secure. In most cases, using logon scripts (especially batch scripts) is not recommended. Instead, GPO or Intune, or another solution that requires secure connections, should be used. It’s fortunate that you came across this issue because it serves as a valuable reminder that even correctly implemented security tools can cause problems for an organization.
LikeLiked by 1 person
Hi Julian that’s kind of hardcore though. Every environment and requirements are different. Microsoft should had EOL the Logon script feature in Windows Server 2022.
LikeLiked by 1 person
I completely agree with you. Every organization is unique and has different requirements, but prioritizing security should be a top priority for all. In my experience, organizations that have suffered from security breaches often regret not prioritizing it earlier. It’s our responsibility to advise customers on using more secure and scalable methods instead of relying on outdated practices like clear text and unsigned batch scripts. Please don’t feel judged for what you were asked to do. By the way, I really enjoy reading your blogs! However, it’s important to stress that security must be a collective effort and every organization should prioritize it. Regardless of our roles, we all have a part to play in ensuring security.
LikeLiked by 2 people
Well, that’s not an easy thing, however if you try to use unsigned PowerShell scripts you will have a tough time either for logon/startup scripts. For batch files, I wouldn’t even mention them as they are a thing of the past (whoever uses them, they should start considering a strategy change) and they can’t be signed.
LikeLike