Forum Replies Created
Sites found using Google confirm these file types under 2016, but your comment about missing VHDX files doesn’t make any sense. VHDX files are the disk drive files for any VM. Have a look at the settings for any VM you have defined, and see what path is given for any disc drive, IDE or SCSI, for that VM. You’ve got VHD or VHDX files, somewhere.
Apologies, confuseis, but my checking shows that you’ll either have to check each client machine, or use the Event Forwarding capability available since server 2008 to get the clients to forward your desired events to the Subscription host as a central collection, and query that store. As an aid, Google has found a site which I think will explain things very well about Event Forwarding: “https://blogs.technet.microsoft.com/jepayne/2015/11/23/monitoring-what-matters-windows-event-forwarding-for-everyone-even-if-you-already-have-a-siem/”.
Your script works as written on a client’s Security log, but that same event is not duplicated on the DC. There are other events written on the DC, but if you use roaming profiles and profile folder redirects, all of those access credential checks are logged in the same time interval, so you end up with a huge load of events for all of that activity.
When you have a domain setup, authentication on a workstation involves security events on the DC. You shouldn’t have to script every workstation to track logins. I’ll have to have a look at my domain system at work to see what your script instruction will reveal. I’m assuming you can see that event if you look at the security logs? If you can, but your script isn’t giving you results for that event, then the script command needs adjustment. My customer site uses a 3rd-party tool for log event monitoring, so I haven’t had to try Powershell for extracting this.
As well, if you’re running server 2008R2 or newer, with Win7 or newer, you should be able to use ‘event forwarding’ from your clients to pretty much any server to hold that info, so you still wouldn’t need to run your captures against the clients. Just scan what’s recorded on the server.
If you’re interested in tracking local machine admin logins as well as domain user/domain admin, then you may have no choice but to have your script solution running on the clients. A login is a check of creds against a security catalog. In a domain, all logins check creds agaists Active Directory. But even in a domain, if you use the local machine administrator creds, you’re using that machine’s own security catalog, not the domain. Regarding my earlier comment about event forwarding, I assume your forwarding rule would include such events in this case, but again, I’ve never tried it.
Active Directory deals with all logins, interactive or otherwise. What you want to do is monitor the security logs for all successful logins, but inside each one of those events will be a numeric value which tells you what type of login it was: interactive, RDP, etc. Using our old friend Google, a search for “active directory login types” comes up with a wealth of info about this. The first link gives you a list of login types vs their numerical values as seen in the events:
1 – Interactive. Console Logons basically.
2– Network. This logon happens when you’re accessing file shares using SMB for example.
3– Batch. …
4– Service. …
5– Unlock. …
6– Network Cleartext. …
7– New Credentials. …
8– Remote Interactive.
Use your script to search the Security log on each DC you have, and only record the events with Logon Type = ‘1’. Of course, this assumes you have success auditing turned on for your security info, so there’s an event log to read from.May 5, 2019 at 1:47 pm in reply to: How to change Information management policy settings with PowerShell (SP2013) #617014
By searching on Google with this string: “sharepoint 2013 information management policy changes powershell”, the first 2 or 3 hits are very informative about what you’re trying to do. The Technet article shows one person’s in-work code, and then he posts his own working corrections.
One possible solution, found thru our friend Google, could be Team Viewer. You sign up for an account, and on the remote PC, get someone to log into that account and install that software. The installation finishes with some details about codes you would use to connect to that PC remotely, so you can do your thing. But, if you’re already having disconnect issues with Chrome Remote Desktop, you may need to look at underlying network stability at the remote location, or even from your own end, as a first step.January 15, 2019 at 4:35 pm in reply to: Getting Operating System ReleaseID info for all the Computers connected to my AD #612937
Based on a quick Google search, an article at https://ss64.com/nt/ver.html gives the following command, and also describes the whole version issue in good detail:
(Get-ItemProperty -Path “HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion” -Name ReleaseId).ReleaseId
You’ll have to supply a listing of all your domain PCs, and loop thru each PC name with the command above, and dump the results each time to an output, such as a text file. The basic structure would be:
List of PC Names or read directly from AD
For each Name
Run the instruction above
Append each result to a text file
Repeat the loop for each Name
FYI for anyone who’s interested: you can replace major hardware (mainboard, CPU, RAM) and not have to buy a new Win10 license. As long as you A) have the license key for your install and B) have added a Microsoft online account to the existing activation on that PC (mine was a gmail acct), you can re-activate once you’ve installed all the new hardware. But, if you took advantage of the free rollout of Win10 on a Win7 machine, your re-activation key is the original Win7 key. If you use something like Magic Jelly Bean KeyFinder to get your Windows key from the registry before the h/w change, what you’ll get is the current Win10 key. But that key won’t work for activation, only the original Win7 key you installed Win10 on top of will work.
I replaced the mainboard, CPU & RAM in a single pass. At next bootup I installed the various drivers, and then re-activated. At first the process failed, reporting that the MS site was offline and try again later. Or just go to the MS store and buy a new license. Using the Activation Troubleshooter, there’s an option to change the license key–that’s where you re-enter the original key that activated Windows with the old OS. Once that key’s in, you should be prompted to re-activate. Barring any issues, you should be done at this point.
Thanks, haven’t used sysprep since I stopped using Ghost for imaging (10 yrs?). Late last night I found some MS articles which tell you about doing just what I’m doing. It appears that licensed Windows 10 hardware can be upgraded without buying a new Windows license, with a couple of precautions. Now I just have to check the backups, etc. Cross fingers!
Blood, have you tried searching the registry for that service name, or some part of it like ‘fieldmili’ or ‘miliservice’, for example? Or how about just looking at reg keys like “Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run” or “…RunOnce”, and of course the Wow6432 node of same: “Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run” or “RunOnce”, to see if there’s anything called out which you can’t otherwise account for.
Granted that’s a bit manual, but esp. if it’s some legacy thing that (big assumption here, based on the computer name) the NHS still has on its systems, it may be the only way to identify the guilty party.
Somehow that PC at ….106 has been added as a DC in your domain, and the previous, failed DC is still there as well. Time to clean up your domain info (metadata). Doing a quick search (Google) I found a link that give you commands for ‘ntdsutil’ which should help you, one wrong DC at a time. The link is:
In addition to what this page calls out, also make certain there are no AD roles/features/tools on that PC, so it doesn’t become re-added back into the metadata.