I'm trying to use Windows SIM to generate a somewhat random computer name for a bunch of new computers we will be deploying Windows 10 using WDS. I know how to use SIM to auto-add the computers to the domain and plan to do so. I do not plan on using MDT since it is not a good choice for my organization.
I want something like LT-DepartmentName-## where the ##s are sequential numbers for each computer imaged. I also don't want them having the same name as another computer in AD. How can I do this? Is it easier just to rename the computer after they are joined to the domain?
Yes, you can have Windows generate a unique computer name, but it might not work the way you had hoped.
The computer name is limited to 15 characters, i.e. department name likely won't fit
The uniqueness is a random string, not sequential number
the generated name is either completely random or based (in part) on the full name and organization name specified in the Microsoft-Windows-Setup -> UserData section of the answer file
For more info see the documentation at https://learn.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-shell-setup-computername
Related
Is there an easy way to take a very long filename (which contains parameters and settings that were used to generate the file) and shorten it programmatically so it will save on Windows?
The filename cannot be sent to a URL shortening service (Bitly, Google, etc.) because the information is confidential and the network is segregated.
The filename has to be shortened internally within the application and without using third-party library and without sending the result to a database.
e.g. Start with a file name so long that Windows will fail to save it:
E:\Results\Job\<SomeJobComponentName>\[A very long file name with the parameters and settings that were used to generate it].csv
And save it as
E:\Results\Job\<SomeJobComponentName>\0eVfd878swg9.csv
And then when the file is read, the code can convert
0eVfd878swg9.csv
back to
[A very long file name with the parameters and settings that were used to generate it].csv
Sort of like a Bitly for filenames.
This is not about encrypting the CONTENT of the file. It's simply about making sure that filenames of any length can be saved without hindrance. The filename needs to be convertible back to the original without opening the file, so that the un-shortened filename can be parsed and viewed in a viewer (which the user uses to browse the result files in the job directory).
I've previously tried the "\?\" prefix to the full path but for whatever reason this fails when using StreamWriter. It can't handle this workaround.
Let me know if I'm barking up the wrong tree here!
Using C# 7.0, Windows Server 2012 R2 and Windows 10 desktop.
According to your question you want to start with a filename so long that Windows will fail to save it. The limit is 255 characters per component (bit between backslashes: folder or filename) and very nearly 32,767 characters, or about 9 A4 pages, for the entire path, which should be sufficient for most normal purposes.
If you are dealing with a filesystem other than NTFS (for example FAT, NFS, ISO-9660) then the limits are considerably tighter. This is about NTFS on Windows 10 Anniversary Update (2016) or later.
While Windows will save and retrieve a file with a path this long, it is possible that some APIs will not. This answer assumes that the file is actually saved under the name you want, but you have to pass a shorter name to such an API.
If the path or filename really is so long that Windows cannot save it, then the file cannot actually exist under that name, and you will have to put the name somewhere outside the filesystem, and one of your constraints is without sending the result to a database, so that possibility is ruled out.
There are two approaches to compression. One exploits redundancy in the data you want to compress, for example run length encoding or Huffman. But that won't work here. There is unlikely to be enough redundancy in the names to make a significant difference. The other is to generate short names and maintain a lookup table. That is what bitly does. Since you have disallowed creating your own lookup table (without sending the result to a database), your only option is to use built-in Windows facilities.
When you save a file in a modern version of Windows, the filesystem will automatically make a short 8.3 filename that will allow the file to be seen and opened by legacy applications. You can retrieve the short filename very simply, like this:
>>> import win32api
>>> win32api.GetShortPathName(r"E:\Dropbox\Rocket Cottage\Sicilian fennel and orange salad with red onion and mint.fdx")
'E:\\Dropbox\\ROCKET~1\\SICILI~1.FDX'
To convert back:
>>> win32api.GetLongPathName(r"E:\Dropbox\ROCKET~1\SICILI~1.FDX")
'E:\\Dropbox\\Rocket Cottage\\Sicilian fennel and orange salad with red onion and mint.fdx'
If using win32api falls foul of your requirement not to use a third-party library (though in a Windows installation that, frankly, borders on religious mania) then you can use subprocess to call dir /X.
C:\Users\xxxxx>dir /x E:\Dropbox\ROCKET~1\SICILI~1.FDX
Volume in drive E is Enigma
Volume Serial Number is D45D-0655
Directory of E:\Dropbox\ROCKET~1
2013-04-17 18:07 17,125 SICILI~1.FDX Sicilian fennel and orange salad with red onion and mint.fdx
C:\Users\xxxxx>dir /x "E:\Dropbox\Rocket Cottage\Sicilian fennel and orange salad with red onion and mint.fdx"
Volume in drive E is Enigma
Volume Serial Number is D45D-0655
Directory of E:\Dropbox\Rocket Cottage
2013-04-17 18:07 17,125 SICILI~1.FDX Sicilian fennel and orange salad with red onion and mint.fdx
The best answer appears to be to upgrade to Windows Server 2016 or later and switch on long file names.
There is no point fighting an uphill battle work around on outdated server operating system when a permanent & official solution is easily available.
Thanks everyone for all the comments.
Let's take for example notepad. How can I in my application be 100% sure whether notepad is running or not?
By 100% I mean, if there is another process whose name is "notepad.exe" which in fact is not a real notepad but for example an imitation, I don't want to detect it. Only real notepads.
I've already thought about reading the process memory but it's more difficult than it appears to be, because of memory displacements etc.
The standard way is by name, right? But for me it is really important, that it is not any other program since I want to interact with it what would critical fail if I found a wrong process.
Does anyone know a good way of doing this?
PS: There is no specific programming language to do it in. If possible I would prefer an indipendent solution. But if required, I specifically use .Net/C#.
The only way to be 99.9%1 sure you're looking at the right executable is to validate the file's digital signature. For example, you'd ensure that the notepad.exe in question was signed by "Microsoft Corporation".
I'd do something like this:
Get the list of running processes.
Filter down to name of interest (notepad.exe)
Get each process' image [executable] path.
Validate that the Authenticode signature is valid and trusted.
Compare the name of the signer to the expected value.
Success! You can be very certain this is the correct file.
This method avoids issues like having to know ahead of time where the file should be located (which is nearly impossible – Notepad is installed in two locations), what its hash value should be (obviously bound to change), or strange user behavior (replacing Notepad with some other text editor).
1 - of course, it's impossible to be 100% sure. Someone really determined could self-sign an executable with the expected signer name and add the certificate to their machine's root store, causing the signature to appear valid.
Well, I haven't been confronted to that kind of problem, but you can first check if the process is running by searching by name (in your case, that would be notepad.exe), parse the Process.GetProcesses() list for that, then get
Process.StartInfo.FileName
and see if this is the path to the Notepad executable, that would do the deal, right ?
What exactly do you know of the executable we want to be running? If you knew the filesize that could work as a "hack". Use #josh3736 's method, but replace point 4 and 5 by comparing the filesize with the one you know [different versions will have different sizes, but if there are not too many you can hardcode them]. Calculation a Md5-Hashtag would look more professional, but would do basicly the same thing.
**
If your process has a GUI: you could use EnumWindows for the children to get Edit-Boxes etc. Find something destinctive for your "notepad.exe" and check if it's there.
From what I've read UIDs in Unix are assigned by the administrator while the SIDs are random in Windows. Is there a security reason behind this, or is it just different ways to solve IDs?
Thanks
While you may edit /etc/passwd (and /etc/shadow) by hand on a Unix machine, the standard way to add users is through a useradd utility (or similar) which should automatically assign the next available UID. So they should be assigned automatically rather than by the administrator. SIDs are more complicated (i.e. hierarchical) so assigning them by hand would be even more cumbersome (and besides, you cannot update the SAM database by hand anyway).
As to assigning them randomly, the SID's random part is the Machine SID, which gives SID the advantage of being unambiguous (as opposed to Unix UIDs). For example, if MACHINE1 has local user ALICE and an NTFS volume with some files owned by MACHINE1\ALICE, when you plug this volume into MACHINE2, it won't make a mistake of thinking those files are owned by some local MACHINE2 user which just happens to have the same SID (whether named ALICE or otherwise).
On Unix, if alice had UID 501 on MACHINE1, then then you plug the same volume into MACHINE2 where UID 501 belongs to bob, ls will show the files as belonging to bob (rather than to alice or even to an 'unknown UID').
UUIDs and SIDs are essentially the same thing.
They're a combination of a system specific part and a timestamp, generated according to a specific algorithm (which might be different between implementations, but that's irrelevant).
Essentially they're both semi-random. Maybe some Unix admins are convinced there's some "security" reason for not handing them out or whatever, but that's nonsense.
The windows SID is a GLOBALLY Unique Identifier vs the Unix UID which is not globally unique.
Ok, I have tried to google this and keep running into things that are close, but not quite there. I mess with them for a few hours and can't bridge it across to what I need.
Requirements: Read a list of computer names and add them to specific OUs.
The list can be formated however, but right now I have it as a csv.
/////////
Comp1,Computers,cold,Alaska,mydomain,com,
Comp2,servers,New Jersey,test,temp,training,Room3,trainers,mydomain,com,
Comp3,computers,New Jersey,test,temp,training,Room3,students,restricted,mydomain,com
Comp4,computers,New Jersey,test,temp,training,Room3,students,power users,mydomain,com
////////
As you can see, the domains portion is not the same on all the machines.
I tried using a vbscript but all I would get is "unable to connect to LDap" so I was thinking about storing the lines in an array and using dsadd and building the command line from the variables in the array.
I already have the portion written to browse for the file, and dsquery, dsadd, etc are all on the server that this will be run from.
This is probably a lot easier than I am trying to make it, I tend to over complicate things if I don't finish it right away.
Look at this:
Automating the creation of computer accounts
I am creating a utility that will store data on flat file in a specific binary format.
I want the filename extension to be specific to my application. Is there any reason other than the old 8.3 filename limit for restricting the extension to 3 characters, and if not, what is the limit? Can I have myfilename.MyExtensionSoHandsOffEverybodyElse ?
This is a hold over from the old windows 3.x/MSDOS days. Today, there are plenty of file names that have more than 3 character extensions.
If I remember correctly, Windows XP had a maximum character limit for path names (including the file name) of 255 characters.
In my experience, having seen a few non-3-character extensions I'd say that it's a matter of tradition, and you're perfectly welcome to use myfilename.MyExtensionSoHandsOffEverybodyElse.
The only good reason for doing this is if you plan to support Windows 9x. If you're only targeting XP and later, as with most projects nowdays, the 8.3 thing is irrelevant.
In fact, Windows itself stores things in long-extension filenames in Vista and later, for example, .search-ms for saved searches.
No, there isn't a good reason to limit the extension to 3 characters. However, a shorter, descriptive name is better if a user has to remember it. For example, most people know what a .html or .doc file would contain.
As long as you make a reasonable attempt to avoid naming collisions with major software there shouldn't be an issue. A corollary to that is the fact that unless you create some insanely long extension that will only ever be unique to your software (and even then, it's not guaranteed), the extension you choose will always be subject to name collision by other people's software when they choose their program's data file extension as you are doing here.