Problem: I have just received a computer, pre-installed with Windows. It is equipped with a 1TB disk, partitioned as a whole 😐 (Yes, that’s how HP partition their disk for you). I don’t have time to reinstall the whole thing; and I need to split the disk in two: The operating system, and the rest is for storage.
When I tried to shrink the disk in Windows Disk Management, I can only shrink it for about 500GB, when I used Pirisoft’s Defraggler to view disk content, it’s the files from winsxs directory that were placed at the end of the disk.
This may be some form of “optimization” Microsoft randomized into Windows. Be it or not, my first reaction was to run Windows’s Defrag utility, it reported my disk is 0% fragmented and won’t proceed, the files are still there (I guess they are just too small to be fragmented). Defraggler did worse, it started moving other small files into the area, while what I wanted is moving things OUT of there.
Searching the web proved futile, everyone says there’s no other way than using some obscure utility on a boot disk (my operating system is 64 bit, mind you, and a 32 bit defragger doesn’t sound fine to me) or reinstall the whole thing.
Well, after one day of searching, I finally found MyDefrag , it is sure not pretty, but it really do what it is supposed to do: move your files where you want them to be, and it ran fine on my system. Basically what I did was download MyDefrag, select “cosolidate free space” and click run. Voilà! Things started moving and in 10 minutes, my disk is ready to shrink (this time, Windows allowed me to shrink an additional 450GB). One thing to note though: My Defrag display the disk map upside down, so the end of you disk is at the top of the screen and vice versa.
While most of the stuff I type everyday can be expressed using Latin characters (e.g English and Vietnamese) so I can use Dvorak for them without the need for another keyboard layout. But sometimes I just need to type in a different kind of language, like, what’s the latest くるま model from トヨタ? 😛
The most convenient way to type that in windows is to use the Japanese IME, but the funny part turning on the IME after my Dvorak conversion is I HAVE TO USE QWERTY FOR JAPANESE. It’s easy to say, but it took me 5 friggin’ minutes to figure out why all I can type is あああ 😐
It’s just what happen when you use Windows: every basic function works just fine, but when you want to take it to the next level of customization, something bad happens.
Luckily, I don’t have to abandon my newly learned layout (which I’m getting a better accuracy rate than the old). There’s three ways to do that
Remap your system’s layout
This site show you how and have a nice chart. I found this site first on my search but this have a lot a side effects: First, you have to change your layout back to qwerty and then remap, which could create confusion when you are protecting your user account with passwords (there’s no way you can tell which keyboard layout is in use at the windows logon prompt – a fatal flaw in design I say). Second, this setting is effective system wide, which means non – Dvorak users will never have the chance to share that computer with you.
Remap the IME
Open the MS-IME’s Properties and press the advanced button, you’ll see a mapping table you can edit, just type the Dvorak combination in place of the qwerty ones already there and you can type Japanese, but what happen if you want one or two Romani character in between? This won’t work 😐
There’s nothing a hack won’t fix
There’s a setting in the registry that will let you change the keyboard mapping file for a specific IME and it’s buried in
There you will find a bunch of hexadecimal keys, each correspond to a specific IME: Slovak, US, Dvorak, Japanese, Korean… you name it! The code for Japanese (MS-IME 2002) is E0010411, go there and change the value of “LayoutFile” from kbdjpn.dll (actually a qwerty map) to kbddv.dll (Dvorak map) and restart your computer (This is the only way to restart the IME).
If that didn’t work (Microsoft may as well hiding some other option which will override what you have just overridden somewhere else, oh well…), you may need to go to %systemroot%system32 and copy the kbddv.dll over kbdjpn.dll itself, then restart.
Yup, that’s what I did to get what I wanted – type 日本語 with ドヴォラック :P.
Due to strict requirements of security for finance businesses, a finance company’s network should be isolated from outside environment. This has the effect of shielding making the entire software infrastructure less prone to software invulnerabilities and thus external attacks. However, this does not eliminate the need for software updates since the network’s operation can still be disrupted by internal sabotage or worm infection from careless users.
Since large financial institutions often have management workflows, updates are subject to prior approval by the management and not all updates maybe approved. The process of maintaining software updates manually, which includes downloading, tracking, approving and installing’s cost could escalate as vulnerabilities are discovered over time and software enhancements are made.
As a major software manufacturer, Microsoft is aware of this issue and have developed Windows Software Update Service (WSUS) as a solution for the update management problem. WSUS allows for approval, mass install, provides a central configuration point and thus reduces the maintenance cost.
This document tried to summarize the knowledge needed for installing and applying WSUS’s update model to an isolated network. This includes:
1. The requirements and how to install WSUS under the isolated model.
2. Configuring WSUS and the approval workflow with WSUS.
3. Synchronize update databases between computers.
4. Configure clients to receive intranet software updates.
Figure 1 A typical corporate intranet
The picture above describes a typical “closed-circuit” corporate network, which connects computers within a branch and branches together. This network is isolated from outside environment (e.g. the internet or other non-corporate affiliated networks).
Two servers, disconnected model
Because the update server must be connected to the internet somehow (to receive updates from the root update server – Microsoft’s), the safest model for this application is to utilize two server – one to receive updates from outside and one to propagate updates inside the intranet. Data would be manually synchronized between the two machines by various means like tapes, external HDDs or an ad-hoc network. Tape and HDD synchronization theoretically is the most secure option, since no connection is required between two machines and thus, makes data leaks and network penetrations almost impossible (data can only go in and can’t go out). Also, update package’s integrity is always verified with digital signatures from Microsoft so they can’t be compromised.
Figure 2 Two servers model
Package approvals can be made on the internal server. Subsequent package updates from the external server will not affect existing approvals.
Although being the most secure option, this model is costly to deploy:
It requires an additional server to receive updates from the internet.
It requires additional data containing medium (tapes, HDDs) to synchronize the servers securely.
It takes time to synchronize (updates are usually large – to the extent of terabytes and external storage media is usually slow)
This technical note is focused primarily on how to configure and make servers perform this role.
One server, switching connection model
Figure 3 Switching connection model – update phase
Figure 4 Switching connection model – distributing phase
To avoid the cost of an additional server and updating time, this one-server model can be used. The update server could switch between two connections: one to the internet (to download updates) and one to the internal network (to distribute updates). The switch could be made at anytime because WSUS itself could handle partial downloads.
With this model, penetrations and leaks may occur if a malicious party could install a drone in the update server to execute predetermined commands or probe for data from the internal network. Therefore t is advised that the update server be carefully firewalled and allow only the update service to access the network interface.
Also, the update server must be dedicated to the role can can’t perform other server roles since it could be disconnected from the internal network at any time.
One server, always on model
Figure 5 One server, always on model
This model is similar to the one server, switching model except that both the connection to the internal network and the internet is always on to the update server. This way, the update server can continuously update its repository and distribute the update to internal computers. The update server acts similar to a router that allow the computers in the internal network to access the internet, except that the only kind of data that can get through is updates and this data also subjects to approval in WSUS.
This model requires an additional interface for the update server. However, the server can also perform other roles for the internal network, since it is always connected.
This model is the least secure of all three. It poses a serious security threat to the internal network in case the update server is compromised by a malicious party. Therefore, making sure the update server itself is up-to-date with the latest security patches and strict firewall configuration is a must.
Comparison between models
One server, switch
One server, always on
Medium (Two servers and transfer media setup)
Low (One server and firewall setup)
High (Update approval on internal server and decide when to sync.)
Medium (Need to decide when to switch)
Low (Update approval only)
High (Manual sync.)
Medium (Manual/Automatic switch required)
Low (Usual security and maintenance checks only)
Configuring WSUS servers
WSUS setup process is straightforward. A configuration wizard is started after WSUS installation is completed to help users configure WSUS. This wizard can be accessed later through the option item in WSUS configuration snap-in (Control panel à Administrative tools à Microsoft Windows Server Update Services)
WSUS can be configured to pull data from another WSUS server instead of the default Microsoft server (useful when deploying the two server model, connected with an ad-hoc network). Other configuration options are visible on Figure 6 and to the left of Figure 7. It should be noted that this wizard should not be followed on the internal server in the two server model since it requires a direct connection to the upstream update server to continue past step 4. Actually no configuration is needed in this case.
Computers in the internal network could be configured into groups to manage which update should or should not be installed on them. WSUS can only manage clients which have reported to it. Refer to section “Configuring clients” for details on how to configure clients.
Figure 8 Client management screen, listing all active clients
Figure 9 Update approval / rejection
Figure 10 Detailed status report for a client, with report viewer installed
After being properly configured, clients will automatically pull updates from the WSUS server and install them if those update packages are approved and have not been installed already.
Synchronizing update repositories
Deploying the two servers model with tapes and external HDDs require manual export and import of update data. “Update data” includes:
Package executables themselves, which are saved as files in WSUS’ update repository (the default folder is C:WSUSWsusContent and can be changed during WSUS’ setup). This is synchronized simply by copying the content of the entire folder.
Information about the packages such as checksum and verification data, termed “metadata”. See “Exporting metadata” and “Importing metadata” for details.
WSUS requires both kind of data to be synchronized to work.
Usually, the list of available updates and their metadata is downloaded before the update packages themselves. WSUS will not distribute such incomplete packages.
Figure 11 Warning when package’s files have not been downloaded
Syntax: wsusutil export <datafile> <logfile>. This will produce a metadata container file (.cab) and a log file (.log). Both are needed for metadata import. The exporting process could take a while.
Figure 12 Exporting metadata
Syntax: wsusutil import <datafile> <logfile>.
Figure 13 Metadata import
To make client update through the new WSUS server instead of the default (Microsoft’s server), the policy for the domain should be modified as in Figure 14 to point to the new WSUS server: http://<servername>.
Figure 14 Client configuration (illustrated with local policy editor)
To edit corporate policy, you con either use the Group Policy Management Console, right click the OU you want to apply WSUS policy and select create policy, you should now see he Group policy object editor similap to tho above screenshot.
Alternatively, you can open Active Directory users and computers, open the properties windows for the OU you want, select the policy tab and click Add (or edit an existing policy).
After policy modification, it may be necessary to:
Forces refresh the active policy with gpupdate /force (which will be automatically refreshed in 15 minutes anyways).
Clear Internet Explorer’s cache on the client to force reload of update configuration files downloaded from the previous update server.
Reauthorize Automatic updates on the client so it is registered on the update server with wuauclt.exe /resetauthorization /detectnow.
Make sure that Automatic Update for the client is enabled.
Figure 15 Windows XP Automatic updates configuration screen (My computer à Properties)
Upon successful configuration, the client will appear on WSUS configuration snap-in as in Figure 8.