Per Wikipedia and other resources such as Windows Internals book, the SCM gets the data it presents in Services.exe by reading HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder\List and HKLM\SYSTEM\CurrentControlSet\Services.
When you try to create your own process using sc command, the data in the registry seems to match the data you entered. When you cross the data seen in SCM's Services.exe tool, there is a lot of data I couldn't find elsewhere in the system.
For example, Eaphost.
Its display name in Services.exe says "Extensible Authentication Protocol" and it has a really long and descriptive description:
When you look in registry, you get the following, which shows a Description and DisplayName values that look more as a command rather than something else.
It's of course not only in the mentioned service, but in others also.
So, where does the SCM gets the rest of its data?
Related
We are using Turbo.net for Publishing applications. One of this application (designed by our own Company) uses a Broadcast to find devices in the Network and then get a reply by a dynamic UDP Port (30000 - 50000). Opening all These ports on the Windows Firewall is not an Option.
I have therefore tried to specify the exe file in the Windows Firewall. That works but the Problem is, I Need to do this for 200 users. So I want to do this by GPO. Unfortunately the path to the exe is something like this:
%userprofile%\AppData\Local\Spoon\Servers\apps.elpro.com\Users\Firstname.Lastname.Domain\Sandboxes\ECOLOGPROModuleConfigurator__1-4-8-420__en-us__Default__AnyCpu\local\stubexe\0x4D80DB43F65B57C8\ PROModuleConfigurator.exe
The problem is "\Firstname.Lastname.Domain\". I was not able to find a way to use a wildcard for this in the Windows Firewall.
It seems that Windows-Firewall does not allow Wildcards.
Is there an easy fix for this or do I Need to script something and if how?
Thank you!
The fact that it can handle %userprofile% tells you that it's okay with Windows variables, so the thing to do would be to set up more such variables, to pass this path as %userprofile%\AppData\Local\Spoon\Servers\apps.elpro.com\Users\%Firstname%.%Lastname%.Domain\...
Sorry there's not a copy-paste solution for you. It would take some scripting on your end to pull this name data out of Active Directory (or some Linux/Unix LDAP server – whatever your organization is using) and fill these variables on a per-user basis. On the up-side, the variables could have other uses once you get them set up, like naming backup directories on a NAS in %Lastname%, %Firstname% format, and so on.
Exactly how to do this will vary by coding language, by OS version, and by directory service type. The information about this is scattered far and wide, so you'll have to search around a bit. E.g., for how to get an AD user's real names with C# under dotNet 3.0+, see this StackOverflow thread. And there are lots of SO threads with info on using Get-ADUser in Powershell to find and filter by user's IDs and names. This thread on SpiceWorks might also be of interest.
You'll almost certainly need Remote Server Administration Tools (RSAT) for Windows (see that page for installation details, which are totally different depending on OS version, even within Windows 10!). Tools that deal with ActiveDirectory need the AD stuff in RSAT to do their work, including both Powershell and C#.Net. RSAT requires Windows Pro or Enterprise (on the machine you're going to use to do the AD work; user workstations can be any version). But AD itself requires Windows Server.
This is only going to be doable with an Active Directory or other LDAP server, in which this user firstname/lastname information, as such, is even stored. Local accounts do not have this information at all except when they inherit it in munged "full name" form, e.g. from Microsoft.com account credentials. In Powershell, you can run 'Get-LocalUser | Select *', or follow the more "deep dive" local-ADSI method demonstrated here, and you'll find no first and last name data. It's just not part of an account, absent some systemic means (AD, or Microsoft online account connection, or Microsoft Family Group management, etc.) of injecting it. There are multiple ways of manually adding "full name", but even doing this across a bunch of users probably would not help you, since human names are not easily software-parseable into first name and last name (Many people have two last names, and many have two or more given names; so what is "Pat Morgan Otero"? And of course given-name versus family-name order varies culturally.) There appears to be no way to add separate first and last name fields to local accounts; tools like Set-LocalUser cannot do it.
[aside]There's no connection between Windows user data and Windows Subsystem for Linux user data (even the usernames can be different), so that's no help. If you have a network-wide unified user ID system via LDAP or whatever, and it has an end result of everyone's user IDs and their real names being in account information under any Linux/Unix system on your network (print server, NAS, anything you can get privileged shell access to), then you might have an easier go of it, given the text-processing tools available to bash in Linux/Unix (including macOS), like grep and sed and awk. All you'd need is a command-line tool for accessing LDAP (or whatever) to run directory queries, then parse the results for name information. Or that name info might even already exist in that Linux box's passwd file. This was how I did something similar for one client, but it was a Linux-heavy shop. If you have any (or most) users isolated from Linux in a Windows-only sphere of users, then this approach would not work.[/aside]
It looks like accessing AD data (or LDAP, whatever) in Windows with Windows-based scripting/programming is the only certain way to do what you want to do. Even then, it will only work if the data is present and correct. You'd need group policy that doesn't permit people to change their names (e.g. by removing their surname) once their account is configured, and human procedural rules that admins must enter this data when setting up accounts, and that it be correct and complete (not missing surname, and not be placeholder or role data that might be substituted out later or might even occur on multiple machines).
PS: Ultimately, I think you should write to the creators of that software and ask them to stop using first and last names in paths, as it breaks the administrability of their product.
Windows Resource Monitor displays (among other things) which files on disk are currently accessed by which processes. And it does that in realtime. How?
I know that it probably uses ETW and that I can generate traces with tools like xperf. But how to get realtime information without having to start, stop and parse a trace file?
I need to programmatically access the data, i.e. from C# or C++.
wOpenTrace/ProcessTrace/StopTrace can get the data in real-time as long as you know the provider GUID. They can run on Win2000 but you need to parse the raw data in your callback functions. To convert raw data into human-readable text, we need the TMF/MOF. Not sure if they are public though.
For Vista/Win7, there is a new set of TDH (Trace Data Helper) APIs (eg: TdhFormatProperty).
Scroll down a little of above links and you can see them. The good thing about TDH is they can parse the data for you (still need to provide TDH the TMF/MOF though).
I tried to write my own .etl to readable .txt program using Open/Process/StopTrace API (because I need to support XP). I found out it's quite difficult. The TMF file is not hard to interpret since it pure text. The hard thing is to decipher more than 50 different undocumented prinf-alike format-specifications' internal structures. So I gave up in the end and stick to the powerful tracefmt.exe provided in Microsoft WDK.
In what way is the Windows registry meant to be used? I know it's alright to store a small amount of user preferences, but is it considered bad practice to store all your users data there? I would think it would depend on the data set, so how about for small amounts of data, say, less than 2KB, in 100 or so different key/value pairs. Is this bad practice? Would a flat file or SQLite db be a better practice?
I'm going to take a contrarian view.
The registry is a fine place to put configuration data of all types. In general it is faster than most configuration files and more reliable (individual operations on the registry are transacted so if your app crashes during a write the registry isn't corrupted - in general that isn't the case with ini files).
Marcelo MD is totally right: Storing things like operation percentage complete in the registry (or any other non volitile storage) is a horrible idea. On the other hand storing data like the most recently used files is just fine - the registry was built for just that kind of problem.
A number of the other commenters on this post talking about the MRU list have discussed the problem of what happens when the MRU list gets out of sync due to application crashes. I'm wondering why storing the MRU list in a flat file in per-user storage is any better?
I'm also not sure what the "security implications" of storing your data in the registry are. The registry is just as secure as the filesystem - the registry and the filesystem use the same ACL mechanism to protect their data.
If you ARE going to store your user data in a file, you should absolutely put your data in %APPDATA%\CompanyName\ApplicationName at least - that way if two different developers create an application with the same name (how many "Media Manager" applications are there out there?) you won't have collisions.
For me, simple user configuration items and user data is better to be stored in either a simple XML configuration file, a SQLLite db, or a MS SQL Server Compact db. The exact storage medium depends on the specifics of the implementation.
I only use the registry for things that I need to set infrequently and that users don't need to be able to change/see. For example, I have stored encrypted license information in the registry before to avoid accidental user removal of the data.
Using the registry to store data has mainly one problem: It's not very user-friendly. Users have virtually no chance of backing up their settings, copying them to another computer, troubleshooting them (or resetting them) if they get corrupted, or generally just see what their software is doing.
My rule of thumb is to use the registry only to communicate with the OS. Filetype associations, uninstaller entries, processes to run at startup, those things obviously have to be in the registry.
But data that is for use in your application only belongs in a file in your App Data folder. (whiever one of the 3+ App Data folders Microsoft currently wants you to use, anyway)
As each user has directory space in Windows already dedicated to storing application user data, I use it to store the user-level data (preferences, for instance) there.
In C#, I would get it by doing something like this:
Environment.GetFolderPath( Environment.SpecialFolder.ApplicationData);
Typically, I'll store SQLite files there or whatever is appropriate for the application.
If your app is going to be deployed "in the enterprise", keep in mind that administrators can tweak the registry using group policy tools. For example, if firefox used the registry for things like the proxy server, it would make deployment a snap because an admin can use the standard tools in active directory to set it up. If you use anything else, I dont think such things can be done very easily.
So don't dismiss the registry all together. If there is a chance an admin might want to standardize parts of your configuration across a network, put the setting in the registry.
I think Microsoft is encouraging use of isolated storage instead of the Windows registry.
Here's an article that explains how to use it in .Net.
You can find those files in Windows XP under Documents & Settings\\Local Settings\ App Data\Isolated Storage. The data is in .dat files
I would differentiate:
On the one hand there is application specific configuration data that is needed for the app to run, e.g. IP addresses to connect to, which folders to use for what sort of files etc, and non trivial per user settings.
Those I put in a config file, ini format for simple stuff, xml if it gets more complex.
On the other hand there is trivial per user settings (best example: window positions and layout). To avoid cluttering the config files (which some users will want to edit themselves, so few and clearly arranged entries are a must), I like to put those in the registry (with conservative defaults being set in the app if no settings in the registry can be found).
I mainly do it like istmatt sais: I store config files inside the %APPDATA% folder. Usually in %APPDATA%\ApplicationName, I don't like the .NET default of APPDATA%\CompanyName\ApplicationName\Version, that level of detail and complexity is counterproductive for most small to medium sized applications.
I disagree with the example of Marcelo MD of not storing recently used files in the registry. IMO this is exactly the volatile sort of user specific information that can be stored there.
(His example of what not to do is very good, though!)
To me it seems easier to think of what you should NOT put there.
e.g: dynamic data, such as an editor's "last file opened" and per project options. It is really annoying when your app loses sync with the registry (file deletion, system crash, etc) and retrieves information that is not valid anymore, possibly deadlocking the user.
At an earlier job I saw a guy that stored a data transfer completness percentage there, Writing the new values at every 10k or so and having the GUI retrieve this value every second so it could show on the titlebar.
I want to store some information in the EPROCESS structure of the process in windows NT kernel. My aim is that when winlogon is called I want to assign a unique value to the next process based on which user logs in. But I do not know where to store this unique ID. I have tried and succeeded in modifying some information (like the tokens) in the EPROCESS block of a process by the method of Direct kernel object modification and I wonder if there is any structure in this EPROCESS block where some other information can be stored.
p.s. For modifying the EPROCESS block I used a device driver.
The EPROCESS structure is opaque and undocumented, meaning you shouldn't be messing with its internals. Doing so requires you, among other things, to test on every OS version and service pack you plan on supporting.
Do not modify EPROCESS. It will bring you great sorrow.
Furthermore, if you do, do not install it on anyone elses machine. It is absolutely wrong to impose such a profoundly damaging, system destabilizing change on another persons computer. How would like it if I gave you tuberculosis?
I need to get some information that is contained in the MFT on a Windows machine, and I'm hoping that there is some super-secret API for getting this information. I need to be able to get to this information programmatically, and because of legal concerns I might not be able to use the tools provided by the company formally known as sysinternals.
My other option (which I really don't want to have to do) is to get the start sector of the MFT with DeviceIoControl, and manually parse through the information.
Anyway, in particular, what I really need to get out of the Master File Table is the logical sectors used to hold the data that is associated with a file.
There is a documented API for getting info on file positions on disk since Windows 2000. Look for DeviceIoControl function with FSCTL_GET_RETRIEVAL_POINTERS control code on MSDN:
http://msdn.microsoft.com/en-us/library/aa364572(VS.85).aspx
The API has been provided for writing custom disk defragmenters and consists of several other control codes.