## Posts Tagged ‘workaround’

### Adobe Creative Suite 6 Installs Very Slowly

March 1, 2013

[Additional 2014-01-10: the same issue occurs with Adobe Creative Cloud and the CCP.  In this case the outbound attempts are on both port 80 and port 443, so you’ll need two rules.]

Here’s the scenario: when using AAMEE (the “Adobe Application Manager Enterprise Edition”) to install Adobe Creative Suite 6 on a machine [1] on an isolated LAN (i.e., a machine with no direct connection to the internet) it takes a very long time to install.  A very, very long time.  During most of this time CPU and disk activity are minimal.

It turns out that the installer is trying to contact various web sites on the internet, including crl.verisign.net, presumably in order to see whether any of the digital certificates on files in the install media have been revoked.  When the attempt times out, the installer continues, but it makes many such attempts.

The workaround I recommend is to install an outbound Windows Firewall rule blocking web traffic.  Windows then instantly fails any attempt to contact a web site.  You can do this from an administrative command line like this (split for readability):

netsh advfirewall firewall add rule name="block www" dir=out
action=block protocol=tcp remoteport=80

To remove the rule later, this is the command:

netsh advfirewall firewall delete rule name="block www"

So how much time does this save?  Well, on one of our new machines, the installer takes 30 minutes if the firewall rule is in place.  Without it, it takes five hours.

I’ll be raising this with Adobe and perhaps, if we’re lucky, the next version won’t be quite so vigorous in its efforts to check the digital signatures.  In the meantime, you may find this approach useful.

[1] The same problem may exist when using the regular installer; I haven’t checked.

### Forcing Windows to identify a special-purpose network

February 3, 2013

One problem that comes up moderately frequently when dealing with Windows servers is that the Network Location Awareness service (NLA) doesn’t allow you to assign a particular adapter to a particular network.  On ordinary networks NLA seems to do a reasonable job, but typically it can’t cope with special-purpose networks such as SANs or point-to-point links; these are all lumped together as the “Unidentified Network” which by default is contained in the Public network profile.

Why is this a problem?  Because the Windows Firewall is configured on a per-profile basis.  That’s fine if Windows Firewall doesn’t interfere with whatever you’re doing on the special-purpose network.  Unfortunately, sometimes it does.

If you search the internet, you’ll find a number of scripts which change which network profile the “Unidentified Network” is put into.  You can also do this with group policy.  This means you can make unidentified networks Private, and turn Windows Firewall off (or set relaxed rules) for Private networks.  Is this a solution?  Not really, because it doesn’t just affect your special-purpose network, it affects every unidentified network from now on.  So if, for any reason, NLA ever fails to identify the network associated with your primary internet connection, your firewall will go down.  I’m not happy about that.

I’ve found a possible workaround.  IMPORTANT: I haven’t tested this thoroughly, and at the moment I’m not planning to use it on my production server (or at least only if every other option fails).  I’ve only tried it on Windows 2012 although I suspect it will work on older versions as well.  It is entirely possible that it only works for certain ethernet drivers.  Try this only at your own risk and please take proper and adequate precautions.

In addition to adapter settings such as the DNS prefix, NLA uses the default gateway’s MAC address to uniquely identify the network.  Special-purpose networks don’t generally have a default gateway; if yours does, you probably don’t have this problem in the first place!  The idea is to create a fictitious default gateway, with suitable parameters, and the trick is that you have to give the fictitious gateway the same ethernet address as the local network adapter on the special-purpose network in question.  If you give it a make-believe ethernet address, it won’t work; you could instead give it the address of another machine on the same network, but then it won’t work if that machine is ever off-line.

(If your special network is a point-to-point link, you might instead prefer to specify the actual IP address at the other end of the link as the default gateway, if you don’t mind that NLA will see it as a new network if the ethernet address ever changes.)

So, for example: when I use get-netadapter in PowerShell I see the following results:

PS C:\Users\Administrator> get-netadapter

----                      --------------------                    ------- ------       ----------             ---------
Ethernet 2                Broadcom BCM5709C NetXtreme II Gi...#42      13 Disconnected 00-10-18-EC-7F-84          0 bps
SAN 2                     Broadcom BCM5716C NetXtreme II Gi...#41      15 Up           08-9E-01-39-53-AB         1 Gbps
SAN 1                     Broadcom BCM5709C NetXtreme II Gi...#43      12 Up           00-10-18-EC-7F-86         1 Gbps
UoW                       Broadcom BCM5716C NetXtreme II Gi...#40      14 Up           08-9E-01-39-53-AA         1 Gbps

In order to assign a specific network to the third adapter (interface index 12) I would use the following commands:

new-netroute 0.0.0.0/0 -interfaceindex 12 -nexthop 192.0.2.1 -publish no -routemetric 9999
new-netneighbor 192.0.2.1 -interfaceindex 12 -linklayeraddress 001018ec7f86 -state permanent

The first command assigns the default gateway for the interface.  I chose IP address 192.0.2.1 because it is reserved and will never be used by a real device; I suggest you do the same.  We don’t want this route to be published, and we set the metric to 9999 so that it won’t ever be used.  (The system uses the default gateway with the lowest metric.)

The second command assigns the fictitious IP address an ethernet address; as discussed before, we use the same ethernet address as the adapter we’re assigning it to.  Note that the ethernet address must be entered in a different format to that in which it is displayed; just remove the hyphens.  We make the mapping permanent.  (You can use the remove-netneighbor command if you want to remove it later.)

I hope this is helpful.  If you do try it, please let me know how it goes.

### When Guest is the administrator

May 5, 2011

Nommo was kind enough to point me to his latest blog entry which discusses a troubleshooting case where the Guest account had somehow wound up being the only active administrator account on a Windows Vista computer.  This was reasonably easy to reproduce (although I used Windows 7 instead) and, indeed, user management tools don’t work as might be expected.

This is interesting.  In most other respects the Guest account still functions as an administrative account.  At first I thought I understood exactly why this happened (to do with the way LAN Manager handled security way back in the days of DOS) but a bit of experimentation showed I was wrong.  It now looks as though a Guest logon is tagged in some way and prohibited from doing any user management – the Guest account can’t even look up its own details – unless you elevate to it from another account, in which case it has user-level access to account management but not administrator-level.  Weird, huh?

Only the actual Guest account is affected; other accounts that are in both Administrators and Guests are not.

Because only account management is blocked, you can get around this in a few ways.  Probably the simplest in most cases is to download the psexec tool from Microsoft.  Start an elevated command-line window by typing “cmd” into the “Search Programs and Files” box in the Start Menu and pressing Control-Shift-Enter.  Then type:

cd /d c:\directory\where\psexec\was\downloaded\to
psexec -s \\127.0.0.1 net localgroup Administrators /add myusername

pressing ENTER after each line and changing “myusername” to the username of the other (currently non-administrative) account.

Alternately, you could edit the registry as described in my earlier post but you don’t need to boot from external media:

1. Go to the Start Menu and type “regedit” and press ENTER.
2. Open HKEY_LOCAL_MACHINE, then SYSTEM, then Setup.
3. Double-click on SetupType in the right-hand pane.  Enter 2 and press OK.
4. Double-click on CmdLine.  Enter cmd.exe and press OK.
5. Reboot the machine.  A command window should appear.
7. Type: “exit” and press ENTER.

Again, “myusername” should be replaced with the username of an existing, non-administrative account.  After this procedure, the account is administrative.  You could also use “net user myusername newpassword” to change the password if necessary.  (The same caveat applies as in my previous post: doing this permanently locks you out of any encrypted files in the account.)

Now, obviously Guest shouldn’t be an administrator.  The fact that things behave oddly in this situation is not a bug.  However, if Guest is an administrator the normal recovery options don’t work properly.  In particular you are supposed to be able to log in as Administrator if no usable administrative accounts exist, and in this situation you can’t, and this is a bug.

Hope this helps.

### Installing 32-bit software as SYSTEM in Windows 7 x64

February 20, 2011

Hi,

I recently ran into an issue updating the Sun Java runtime on our x64 machines.  We don’t have the budget for fancy deployment solutions, so we just use a startup script (actually an executable, but that’s just fine-tuning) that checks the version number and runs the installer(s) as necessary.

Installing the 32-bit JRE results in error code 1619, which NET HELPMSG translates as “This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package.”  Running the installer in interactive mode produces the same message.  The installer works normally when run from the context of a logged-in user.

Several hours of troubleshooting later, I identified the source of the problem.  Startup scripts run as local system.  In Windows 7, processes that run as local system have a special profile found in c:\windows\system32\config\systemprofile.  Unfortunately, on 64-bit systems, there are two system32 folders; one for 64-bit processes,and another (whose real name is syswow64) for 32-bit processes.  As a result, there are two separate system profiles; one for 32-bit, one for 64-bit.

So what?  Well, the Sun Java installer unpacks into a subfolder of the LocalLow application data directory.  In this case, the folder in question is c:\windows\system32\config\systemprofile\AppData\LocalLow\Sun\Java\jre1.6.0_24.  Because this is a 32-bit process, though, it is really writing to syswow64 instead of system32.

The Windows Installer, however, is a 64-bit process.  So when it is asked to open the MSI file, it’s looking in the wrong place; hence error code 1619.  The file can’t be opened because it can’t be found.

The same underlying problem (duplication of the system profile) seems to be the cause of this problem with Known Folders warning 1002 appearing repeatedly in the event log.  Some 32-bit system process is registering folder paths inside the (32-bit) system profile and of course these folders can’t be found by 64-bit processes.

For the problem with installing 32-bit software, there are a number of possible workarounds.  You could manually extract the installer files, copy them to a suitable path on the local system, and run them directly.  Most installers won’t mind this, although some will balk or fail to function properly.  Alternatively (and this is the solution I chose) you could create the necessary directory ahead of time and add a junction point (mklink /J) from the 64-bit profile to the 32-bit profile (note that this command line assumes you are in a 32-bit context, and has been split for readability):

mklink /J c:\windows\sysnative\config\systemprofile\AppData\LocalLow\Sun\Java\jre1.6.0_24
c:\windows\syswow64\config\systemprofile\AppData\LocalLow\Sun\Java\jre1.6.0_24

This is the equivalent command if you are in a 64-bit context:

mklink /J c:\windows\system32\config\systemprofile\AppData\LocalLow\Sun\Java\jre1.6.0_24
c:\windows\syswow64\config\systemprofile\AppData\LocalLow\Sun\Java\jre1.6.0_24

Another possible approach would be to merge the two system profiles together and create a junction point from one to the other.  That would solve this issue for all installers, as well as the Known Folders issue and any other variants.  However, I can’t recommend doing this; it’s too broad a change, and there’s no way to predict what it might break.  If you’re very brave, go ahead, but test thoroughly – and don’t blame me!

Hope this helps.

Harry.

### IOCTL_DISK_GET_LENGTH_INFO doesn’t work on floppy disks

January 12, 2010

I was trying to write a floppy disk image to a physical disk the other day, and my home-made imaging tool was refusing to work.  Once I got around to tracking this down, it turned out that IOCTL_DISK_GET_LENGTH_INFO simply doesn’t work on floppy disks, returning error code 1, ERROR_INVALID_FUNCTION, Incorrect Function.

This happens on both Windows XP and Windows 7, and presumably on other versions as well.  I suspect Microsoft would categorise this as a feature rather than a bug. 🙂

I’m not sure if this is the best workaround, but it’s what I came up with.  Note that IOCTL_DISK_GET_DRIVE_GEOMETRY_EX also doesn’t work for floppy disks.

I haven’t tested this with, e.g., ZIP disks, or with a wide range of USB memory sticks.  Feel free to copy-and-paste this code segment into your own project if it will help, but it comes without any warranty, express or implied.

if (!DeviceIoControl
(
houtput,
IOCTL_DISK_GET_DRIVE_GEOMETRY,
NULL,
0,
&target_diskgeometry,
sizeof(target_diskgeometry),
&byte_count,
NULL
))
{
err = GetLastError();
fprintf(stderr, "Error %u getting output device geometry.\n", err);
return err;
}

switch (target_diskgeometry.MediaType)
{
case Unknown:
case RemovableMedia:
case FixedMedia:

if (!DeviceIoControl
(
houtput,
IOCTL_DISK_GET_LENGTH_INFO,
NULL,
0,
&target_disklength,
sizeof(target_disklength),
&byte_count,
NULL
))
{
err = GetLastError();
fprintf(stderr, "Error %u getting output device length.\n", err);
return err;
}

fprintf(stderr, "Output disk has %I64i bytes.\n\n", target_disklength.Length.QuadPart);
break;

default:

target_diskgeometry.TracksPerCylinder *
target_diskgeometry.SectorsPerTrack *
target_diskgeometry.BytesPerSector;

fprintf(stderr,
"\n"
"Output device appears to be a floppy disk.  WARNING: if this is not a\n"
"floppy disk the calculated output device size is probably incorrect,\n"
"which might result in an incomplete copy.\n"
"\n"
"Output disk has %I64i bytes.\n"
"\n",

break;
}


Hope this helps.

Addendum: note that the figures returned by IOCTL_DISK_GET_DRIVE_GEOMETRY don’t give you the correct device length for hard disk drives, so that’s why this code uses IOCTL_DISK_GET_LENGTH_INFO unless the device is a floppy disk.

### The Provision a Shared Folder Wizard Changes Quota Settings

December 28, 2009

In Windows Server 2008 R2, if the Provision a Shared Folder Wizard is used to share a folder which has a folder quota defined, the quota’s source template is reapplied.  If the quota did not match its  source template, the quota settings will be changed unexpectedly.  If the quota was not created from a source template, the first available template will be applied.

You can select a particular template to apply instead of the source template/first available template, but you cannot prevent a template from being applied.

To work around this problem, create a template that matches the quota on the folder being shared before running the Provision a Shared Folder Wizard, and select this template at the appropriate point.

### Delays when connecting to Windows 7 clients for remote administration

December 18, 2009

OK, this is my first ever blog post.  Bear with me.

If you are remotely administering a Windows 7 client, for example, listing the services on the remote machine using the Computer Management tool or the sc.exe command line, there may be an unexpected delay when connecting.  If you use netstat -a -n during this delay you will see a TCP connection from your machine to the target machine sitting in the SYN_SENT state.  After a little while this connection attempt times out and the operation succeeds anyway.

Another example of a remote administration tool that suffers from this problem is psexec.exe.

This will happen if you are connecting from another Windows 7 machine  (or, presumably, Windows 2008 R2) and the firewall on the target machine is configured by group policy with the “Allow inbound remote administration exception” setting enabled.

The cause: the group policy setting configures one of the relevant firewall rules incorrectly.  The “Remote Administration (RPC)” rule is set to apply to svchost.exe instead of services.exe.  My best guess is that this is a bug in the Windows 7 group policy client.

The problem can be worked around by turning on an appropriate rule locally on the affected clients.  If you are using the GUI, turning on the “Remote Service Management” exception will solve the problem.  From the command line:

netsh advfirewall firewall set rule name="Remote Service Management (RPC)"
profile=domain new enable=yes

Note this is all a single line, but I have split it for readability.  You could use group policy to include this command in a startup script, or run it remotely for each machine using psexec.  It only needs to be run once on each machine.  Note that the command-line version only enables one of the rules associated with the “Remote Service Management” exception, but if you have the above-mentioned group policy exception defined the other necessary rules are already present.

Hope this helps.