Blog

This event could really be due to a couple things, mostly dependencies.
I came across this error notice while checking my workstations event logs. I noticed these events coming from what should be Trend AV. As Trend is an active AV in use I was concerned about it, however the active AV session was OK and showing green across the board.

Entering the exact info from the event into google prompted a nice forum topic about it. I already did my due diligence by checking local service with an admin account both using the “sc query” command and the “Get-WmiObject win32_service | format-table displayname,name,startname.”
This was enough to show me that tmcomm was not an active service installed on my system. Lucky for me the user on this forum was experiencing a similar issue.
This left me to believe these were old services left behind by a previous version of Trend AV..
Following the advice there, removed the service keys from the registry. Browse to HKey_Local_Machine\System\CurrentControlSet\Services under services key, there are many sub keys, find the one named TmComm and delete it, keys look like a folder.
Once I had removed the key and rebooted I had a clean eventlog!

So those are the basic steps, check log, see event, and verify dependencies are starting. If service name cannot be found using the commands listed above then check the registry under HKLM/SYSTEM/CCS/Services and remove the key for the listed service .
Hope this helps someone else experiencing Event ID 7000 in their eventlogs!

Jan 2018 update

Well done.

As a systems administrator you’ll often need to clean up (Group Policies) GP’s in many organizations Windows Domain environments.
Before I get into my story, here is some background info on ADM and ADMX files and templates.

While I was working on cleaning up and verifying processed Policies, I came across one that stated Extra Registry Settings.
Thing to check and note is if the polcies templates are derived from the localstore or a central store.
If its using the local store it will check C:\Windows\inf for .adm files, and C:\Windows\PolicyDefinitions for.admx files.
If using a central store, they will be under PolicyDefinitions under the SYSVOL folder, this is used for replication services.
It’s also important to note that when you add an .adm file to a GP (either User or Computer Category) the adm file gets copied to the policies folder in SYSVOL.

So the first thing I checked was under the poclies ID folder in SYSVOL I found a adm template file, and made a copy of it.
You can open .adm file with notepad, and check here for how they are structured.
After checking the structure of the file it was exactly matched to what was displayed in the Extra Registery settings.
I even enabled the settings, removed the .adm from the GP in GPME, checked the settings tab in GPM and they “Extra Registry Settings” were exactly the same.
I was stumped, I couldn’t figure out what was going on, and the .adm file were in all places Windows would look for them.

I came in this morning and decided to give it one more shot… I just can’t let things go when they bother me, and rebuilding the GPO just didn’t seem like a good solution.
What I did was I took the ValueName, and appended it to the KEYNAME string, I left the Valuename the same, and this was enough to work!
It finally showed the correct heading in GPM, I was able to change their settings, and finally remove the .adm file to have a clean GP!

Jan 2018 Update

It’s been a long time since I had to such things as reverse engineer ADM files. This is a pretty cool post, haha.

Using Windows Easy Transfer is amazing tool for when you want to move all your profile settings and personal files from your old system to your new one.
But like everything it’s not perfect, for instance you can’t go from 64 bit – 32 bit (Who would want to…)
You can’t go from WIndows 7 to Windows 8 (Yes it’ll copy your files but not your settings, should be expected, and only via USB HDD)

and one pet pieve that it doesn’t copy over Outlook sugnatures given its located under a user profile directory (C:\Users on Vista and up versions)

Now copy the files from %APPDATA%\Microsoft\Signatures (%APPDATA% is C:\Users\useraccount\appdata\roaming)
Not to be confused with %localappdata% which is C:\users\useraccount\appdata\local

Since these files are hidden system files I suggest to use xcopy with the /i /e /h options.
You can also adjust Windows explorer folder view settings to show hidden and system files.

Once these Files have been copied to the destination machine with the same user at the same directory,
simply reopen outlook and check your signatures! Boom, they are back baby!

Jan 2018 Update Notes

First off, WET is no longer a thing. I will admit I am very sad to see it go, as a systems administrator it was a thing of beauty and made my life a breeze. Sadly now Microsoft has out sourced this to a partner company “Laplink’s PCmover Express“, and even worse it’s a paid product. I personally think its rubbish, you’d be better off updating/upgrading your software manually and simply moving any associated files with that application manually.

Secondly, You’ll notice the use of Environment Variables. Learn em, use em they are a vital tool to management specially with non-default directories or system drives.