This post is more of a guide than me finding weird bugs and the documention of my adventures trying to figure out what is actually going on. But
even then I came across something new that kind of tripped me up.
A number of departments in the company I work for use various special fonts, which are part of the "Corporate Identity". Whenever a machine in one of those departments gets replaced we needed to install these special fonts on the new machine. And since we have been replacing a couple hundred machines over the last half year and will continue to replace a couple hundred machines every year on a regular basis from now on I decided to take a look at how to automate the deployment of fonts.
As I have mentioned in previous posts we are using Microsoft's SCCM (System Center Configuration Manager) for Windows/Office update and general software deployment. So the tool of choice for the task was of course that. All I needed now was a script that could properly install the fonts and hand that script over to the guy in charge of the SCCM server so he could deploy it to the machines in question.
As already written in the "Windows folder redirection not working ... sometimes" article we are making use of the Windows folder redirection group policies to redirect folders like "Documents", "Desktop" and "Favorites" to a server share in order to save space on the local harddisks/SSDs and of course make that data available to the user no matter what workstations he logs onto. For the redirection we use the environment variable %HOMESHARE% which basically contains the value of the AD field "HomeDirectory".
Until now the folder structure we were using for the home directories was a little odd. The home directories resided in "\\server\users\home\<department>\<accountname>" which means that whenever a user changes department his/her entire home directory had to be moved to a new location.
The server department started moving the first departments' users' home directories to a new structure (and updated the "homedirectory" value in the AD for the affected users accordingly). The new locations for the home directories are five DFSs under "\\server\users\home0[1-5]\<accountname>" hosted on a NetApp server. The split into "home01" to "home05" is done so that they do not have to restore a giant 10TB share and instead only have to deal with smaller 2TB portions when things go south.
And even though the people in charge claimed that they tested everything thoroughly things did go south when they migrated the home directories of the first hundred or so users ...
Update 30.08.: A decision was made as to what to do about this issue. The SCCM client will be monitoring the registry keys, as a form of a watchdog service, and will report any machines where modifications are made to a group of administrators via mail.
Update 29.08.: Apparently "mstsc.exe" offers the same functionality, I was told. Add a DWORD called "shadow" under "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" and set the value to "2". After that you should be able to use the following command: mstsc.exe /shadow:<session ID> /control /noConsentPrompt /v:<remote machine>
Like this the user will not even see a flickering mouse cursor. The only way to tell someone is watching you like this is by checking the task manager and looking for the RDP processes.
Ever wanted to know what your boss is doing all day long? Are you using Microsoft SCCM for operating system and software deployment and do you have local admin privileges on your boss' computer? Then you are in luck!
Update 16.07.: Apparently the VNC viewer also works when I copy the executable to a folder on the local system, rather than executing it from the desktop which is located on a network share. It will also work while on the desktop when I give the user full access to the entire home share (\\<server>\benutzer\home\). Giving him full access rights to just his own home directory (\\<server>\benutzer\home\<department>\<user>) results in the VNC viewer still failing with the "getaddinfo" error.
Two of our departments recently got a new system for their number ticket system. You press a button on a touch panel and get a ticket with a number on it. When that number is called, you proceed to the counter.
The company who delivered the new system pre-installed VNC (at this point I only knew it was *some-kind-of* VNC, later I found out it was a TightVNC server) on the machines responsible for displaying the button to request a new ticket and print the ticket, and the machines responsible for showing which numbers are up next.
Back in March 2017 our department was getting increasing numbers of complaints about abnormally slow remote assistance connections ... but not from our users but from co-workers of the other IT sub-departments. We are using the Microsoft Windows Remote Assistance tool (msra.exe) for when we need to help a user with a problem.
And when I say "slow", I mean _slow_. The lag between input and output easily reached over 1 minute, which made working like that impossible.
Today I was asked to update the EGVP (Elektronisches Gerichts- und Verwaltungspostfach) software on a client. The software is used to send an receive encrypted emails and to verify that the senders are who they claim to be. [official site] [wikipedia]
After I found out that the old client was never installed on the system I found out that until version 2.9 the whole thing was also available as Java WebStart. After 2.9 only an installable msi-version is offered. Ok then, lets hope the new version is smart enough to import all the old settings from the WebStart version I thought ...
We are making use of the Windows folder redirection group policies to redirect folders like "Documents", "Desktop" and "Favorites" to a server share in order to save space on the local harddisks/SSDs and of course make that data available to the user no matter what workstations he logs onto.
Our home directories are a little odd in regards to the folder structure we are using. The home directories reside in "\\server\users\home\<department>\<accountname>" which means that whenever a user changes department his/her entire home directory must be moved to a new location.
This is the story how I found out (by proxy) that the default user profile in Windows 10 is potentially writable by any user and the odyssey of trying to get this security bug fixed ... and failing to do so in the end.
For those who do not want to read the full story I posted a TL;DR version at the bottom. ;)
2017-05-19 19:55 - I got contacted by a friend who asked me for my input on an issue he (or rather his company) was having for weeks and months already and had not been able to figure out yet. Even Microsoft Germany, who they contacted themselves about this issue on 2017-03-28, did not have a solution for them.
Some background: His company is selling servers and support for them. So far, there are over 1.800 of their servers with over 100.000 connected clients and over 1.000.000 users out there and they had a problem with newly deployed Windows 10 systems they were not able to figure out.
I work in the IT department of my home town and am part of the so-called "2nd-Level-Team" in charge of around 3500 Windows computers.
The whole IT department has around 50 employees. The 1st-Level-Team with 5 people is responsible for manning the help desk hotline, inserting tickets for the entire department into the ticket system and fixing simple problems the users have. The 2nd-Level-Team consists of another 5 people who are responsible for everything related to software and operating system issues on the 3500 Windows computers. The servers and network are the responsibility of other teams.
While the members of the 2nd-Level-Team all share the same base responsibilities after two years on this job I've been tasked with quite a few additional responsibilities thanks to my previous job experiences. For example:
I'm in charge of the company-wide Group Policies for all Windows client systems.
I'm responsible for prepping, testing and documenting software for fully automated deployment through SCCM before handing the finished package over to the SCCM guy for the actual deployment.
I've been tasked to figure out how to actually make Microsoft Windows 10 useable in our environment.
I'm also in charge of getting a virtualized desktop infrastructure for up to 100 concurrent users up and running. (The client side of it at least. The server part is done by the servers department)
Last but not least I'm at this point in time the only person in my team with any programming/scripting experience so I get to do all the task automation using Powershell
I'd like to use this blog to document some stories from work, bugs I find, tips and tricks for problems I come across and facepalm worthy moments.
Be warned though, some of the things I might post can potentially make you lose all hope in humanity or at least have an increasing effect on your alcohol consumption. ;)