Today, I had to deal with an HP Pavilion Slimline 400 that would only power on intermittently despite passing all PSU tests. Though I'm fairly sure the power supply unit is OK, I spent some time researching a replacement. What I discovered is that the Slimline 400 with its half-widthness is the only PC model ever to use this style of power supply. I went to a computer store with a bajillion different types of PSUs, but all the normal ones (and crazy ones) they had were always slightly different than this one, different enough to not work.
Previous experiences just reinforce my irritation with PCs with strange form factors or cases. It just makes maintenance and upgrade more difficult. Also, it's super difficult to find parts that fit the special arrangement of the case. Sure, it's not very original, but you know why there are so many generic beige-box PCs?
They work.
Saturday, February 7, 2015
Friday, February 6, 2015
A Better Way of Adding Drivers to WDS Boot Images
Today, I tried to use WDS to deploy to a laptop that had an NIC that the normal WDS boot image couldn't deal with. After a brief display of "Setup is starting", the client threw an error talking about how an error occurred while starting networking. It wanted me to add the NIC drivers to the boot image, so I looked online for instructions on doing that. I found KB923834, which seemed to perfectly match my problem at first. However, I soon discovered that the setup log doesn't contain the error spew the article mentioned and, despite having the Windows AIK installed, I don't have a "Windows AIK" directory in Program Files. Also, I really wasn't looking forward to doing the supercomplicated procedure to solve an issue that can't be that unusual.
So, I continued my search for help and turned up some very nice tutorials on doing this. In summary, that KB article is super old (for Windows Server 2003?) and WDS has come a long way since then. The general procedure for adding drivers to a PE boot image is:
So, I continued my search for help and turned up some very nice tutorials on doing this. In summary, that KB article is super old (for Windows Server 2003?) and WDS has come a long way since then. The general procedure for adding drivers to a PE boot image is:
- Find the NIC driver and unpack it to an INF with supporting files
- Disable the boot image (to prevent it from being sent to a client during servicing)
- Add a driver package (under the Drivers section of the WDS snap-in)
- Point the wizard at the INF and create a driver group if you want
- Open the "add drivers to boot image" wizard for your boot image
- Use the default search terms to search for drivers, check the box for your new drivers
- Complete the wizard and wait a super long time for it to mount, modify, and unmount the WIM
- Re-enable the boot image
Tristan Watkins wrote a more filled-out backstory and procedure (with pictures) for this. It helped me immensely.
Thursday, February 5, 2015
Deploying a Custom Windows Image with WDS, Unattended
I discovered this week that the Windows Deployment Services role on Windows Server is really great. It is possible to create your own customized Windows images to be deployed; you can load up all the software and loose files you want, no matter what type of installer your custom applications have.
The first step to getting a setup like this is installing the OS as normal on one computer. This computer will be used to perfect the configuration of the OS and all the applications and files. Do whatever you need to make the computer as all of them should be, and then generalize its configuration. Open the Sysprep utility, found at:
C:\Windows\System32\Sysprep\sysprep.exe
Choose "OOBE" from the top dropdown list, check "Generalize", choose "Shut down" from the lower dropdown list, and execute the operation. It will take a while to rip out all the machine-specific stuff, and then power off the machine.
Go to the WDS server and add the boot image for the OS, which can be found in the OS installation image (the DVD), as "\sources\boot.wim". Right-click it in the list and choose the option to create a capture image. Run through the wizard, naming it whatever you want. This creates a version of the PE image that will freeze the client computer into a WIM image for WDS. Under Install Images, create a new image group that will eventually hold the custom image.
PXE-boot the client that you just Sysprep'd into the capture image. Run through the wizard, selecting what is probably now called the D:\ drive, putting the temporary local image anywhere on the local main drive, and uploading the image to the server in the empty image group you created earlier. (This requires you to enter your credentials.) Once it completes the upload, turn off the client.
Back at the WDS server, look at the new custom install image. You're done, unless you want to make an unattend script.
To create an unattend script, you'll need the Windows System Image Manager, which is included in the Deployment Tools feature of the Windows Assessment and Deployment Kit. Install that, then export the custom install image in the WDS MMC snap-in. (The WDS image directory is not writable except by the system.) Put it somewhere on your main partition.
Open the Windows System Image Manager. Create a new answer file, selecting that exported image. Create a catalog if it asks. Then, in the lower-left pane, right-click the configuration settings you need and add them to (usually) Pass 1 or Pass 4. Pass 1 (PE settings) is the unattend script for the pre-installation environment. Pass 4 (specialization) holds settings to apply to the computer when it boots real Windows for the first time. Help with this step can be found at TechNet's Components chapter of the WDS documentation.
After you save your file in Windows SIM, open the properties of the custom install image and check the box allowing unattended installation. Specify your answer file. Then, open the properties of the WDS server itself in the WDS snap-in. Set the answer file to be the default for the appropriate architecture.
Congratulations! You can now perform an unattended deployment of a custom Windows image!
The first step to getting a setup like this is installing the OS as normal on one computer. This computer will be used to perfect the configuration of the OS and all the applications and files. Do whatever you need to make the computer as all of them should be, and then generalize its configuration. Open the Sysprep utility, found at:
C:\Windows\System32\Sysprep\sysprep.exe
Choose "OOBE" from the top dropdown list, check "Generalize", choose "Shut down" from the lower dropdown list, and execute the operation. It will take a while to rip out all the machine-specific stuff, and then power off the machine.
Go to the WDS server and add the boot image for the OS, which can be found in the OS installation image (the DVD), as "\sources\boot.wim". Right-click it in the list and choose the option to create a capture image. Run through the wizard, naming it whatever you want. This creates a version of the PE image that will freeze the client computer into a WIM image for WDS. Under Install Images, create a new image group that will eventually hold the custom image.
PXE-boot the client that you just Sysprep'd into the capture image. Run through the wizard, selecting what is probably now called the D:\ drive, putting the temporary local image anywhere on the local main drive, and uploading the image to the server in the empty image group you created earlier. (This requires you to enter your credentials.) Once it completes the upload, turn off the client.
Back at the WDS server, look at the new custom install image. You're done, unless you want to make an unattend script.
To create an unattend script, you'll need the Windows System Image Manager, which is included in the Deployment Tools feature of the Windows Assessment and Deployment Kit. Install that, then export the custom install image in the WDS MMC snap-in. (The WDS image directory is not writable except by the system.) Put it somewhere on your main partition.
Open the Windows System Image Manager. Create a new answer file, selecting that exported image. Create a catalog if it asks. Then, in the lower-left pane, right-click the configuration settings you need and add them to (usually) Pass 1 or Pass 4. Pass 1 (PE settings) is the unattend script for the pre-installation environment. Pass 4 (specialization) holds settings to apply to the computer when it boots real Windows for the first time. Help with this step can be found at TechNet's Components chapter of the WDS documentation.
After you save your file in Windows SIM, open the properties of the custom install image and check the box allowing unattended installation. Specify your answer file. Then, open the properties of the WDS server itself in the WDS snap-in. Set the answer file to be the default for the appropriate architecture.
Congratulations! You can now perform an unattended deployment of a custom Windows image!
Wednesday, February 4, 2015
Determining Whether a Windows Installation was Mass-Deployed
Windows OEMs use the Windows Automated Installation Kit and Windows Deployment Services to mass-image computers before shipping. If you're curious as to whether a computer you're using was set up in such a way, you can check for the presence of a file that indicates Sysprep was run. This file is at:
C:\Windows\System32\Sysprep\Sysprep_succeeded.tag
It's a zero-byte file that is created after a successful run of Sysprep, the generalization tool run to freeze a computer before using ImageX (or a WDS capture boot image). If you're curious as to the date of imaging, it's in the action log:
C:\Windows\System32\Sysprep\Panther\setupact.log
Tuesday, February 3, 2015
Port Scanning Isn't Like Trying Doorknobs
I have recently been in discussions about port scanning and the legalities of it, and wherever I read about it on the Internet I find one metaphor that really doesn't make any sense. People liken port scanning to going down a row of houses on a street, walking up to each door on a house, jiggling the doorknob, and noting whether the door would have opened.
This is a severely bad analogy.
It implies that if the port is open - the door is unlocked - attackers or thieves could just waltz in and take all the things. It paints the picture that a single open port would let anybody walk right in and have complete control of the machine. Obviously, this is not the case. It's up to the application listening on the port whether or not the machine on the other end of the line will gain access to the computer. Most applications don't give any unauthenticated user an admin shell. And, of course, an attacker on a particular port can only do things at the privilege level of the application.
In my opinion, port scanning is more like calling a hotel repeatedly and asking to talk to the occupant of a room with whatever number. Some occupants might be more talkative than others, divulging information about the architecture of the building and the arrangement of interesting things. Some particularly gullible could be tricked into opening their room and adjoining rooms to the attacker. Most, however, will just hold a normal conversation, conversing about what they know or do.
This isn't to say that firewalls are pointless. They're a good way to protect network-internal services from the outside world and stop malware from calling home. It's always good to disconnect the phone if you have a particularly naive guest. Likewise, vulnerable yet important services (legacy systems e.g. ye olde SMBv1) should be barred from receiving connections from the outside. Defense in depth is always a good plan, just make decent analogies.
This is a severely bad analogy.
It implies that if the port is open - the door is unlocked - attackers or thieves could just waltz in and take all the things. It paints the picture that a single open port would let anybody walk right in and have complete control of the machine. Obviously, this is not the case. It's up to the application listening on the port whether or not the machine on the other end of the line will gain access to the computer. Most applications don't give any unauthenticated user an admin shell. And, of course, an attacker on a particular port can only do things at the privilege level of the application.
In my opinion, port scanning is more like calling a hotel repeatedly and asking to talk to the occupant of a room with whatever number. Some occupants might be more talkative than others, divulging information about the architecture of the building and the arrangement of interesting things. Some particularly gullible could be tricked into opening their room and adjoining rooms to the attacker. Most, however, will just hold a normal conversation, conversing about what they know or do.
This isn't to say that firewalls are pointless. They're a good way to protect network-internal services from the outside world and stop malware from calling home. It's always good to disconnect the phone if you have a particularly naive guest. Likewise, vulnerable yet important services (legacy systems e.g. ye olde SMBv1) should be barred from receiving connections from the outside. Defense in depth is always a good plan, just make decent analogies.
Monday, February 2, 2015
Gash - Better Bitmaps
I wrote the part of the new NextGenGraphics constructor that carves the xGAGRAPH file apart into chunks. Since decompression doesn't happen immediately, the raw compressed chunks have to be labeled with their size, taking into account the fact that some special chunks have their decompressed size hard-coded (rather than it being the first four bytes of the raw chunk).
I also realized that my existing SixteenColorBitmap class, had I tried to use it here, would have been both poorly named and really difficult to deal with. It doesn't support masking (you need MaskedSixteenColorBitmap for that) and doesn't have a very convenient way of dealing with palettes. So, I wrote a LowColorBitmap class that reduces the craziness (using the .NET Color struct instead of 4-tuples) and has built-in support for masking.
I also realized that my existing SixteenColorBitmap class, had I tried to use it here, would have been both poorly named and really difficult to deal with. It doesn't support masking (you need MaskedSixteenColorBitmap for that) and doesn't have a very convenient way of dealing with palettes. So, I wrote a LowColorBitmap class that reduces the craziness (using the .NET Color struct instead of 4-tuples) and has built-in support for masking.
Sunday, February 1, 2015
Gash - Delay Decompress
One of the most serious issues with the existing FleexCore2 implementation of Galaxy-style graphics was that it always decompressed every chunk as soon as the files were opened. All that bit-twiddling in such a high-level language takes a lot of time, so I had to do the whole workaround with the underscore-prefixed options on GalaxyGraphicsChunkSettings to make Abiathar's EGA loading not take a million years.
To remedy this and include the special CGA/VGA features necessary for Gash, I started an entirely different FleexCore2 class called NextGenGraphics. It uses the .NET Lazy(Of T) class to delay the construction of the graphics objects. Now, chunks will not be decompressed unless the resource they represent is called for. I have not yet started the actual graphics loading for this class, but it should be pretty easy once I figure out how to genericize the code that already exists in GalaxyGraphics.
To remedy this and include the special CGA/VGA features necessary for Gash, I started an entirely different FleexCore2 class called NextGenGraphics. It uses the .NET Lazy(Of T) class to delay the construction of the graphics objects. Now, chunks will not be decompressed unless the resource they represent is called for. I have not yet started the actual graphics loading for this class, but it should be pretty easy once I figure out how to genericize the code that already exists in GalaxyGraphics.
Subscribe to:
Posts (Atom)