V2P [4], Thin PC [4]

A couple of weeks ago I wrote about how our laptops which were set up with native boot VHD would all have to be V2Pd because VHDs on the native boot system tend to get corrupted more often. This week it is time to put that into reality by getting started on the 14 laptops which will be continuing over the next couple of weeks. The first step is to back up the VHD. Then we can mount it to a drive letter using Diskpart commands. We then use ImageX to capture it in place to a WIM. After ImageX is complete we apply the image to the same partition where the VHD was. We then remove the existing BCD from the boot partition (easiest just to format it) and then use bcdboot to create a new boot configuration on the system partition. Then we boot and the laptop should be exactly as it was.

The more experienced of you will probably say I left a step out, and I did. That’s because it shouldn’t have been necessary to sysprep the VHD because we were just moving the image from one partition to another. And because MS have limited the use of sysprep to a maximum number of times it can be done, I try to use sysprep a minimum amount. But regrettably sysprep has proven necessary in this instance, because Windows 7 will detect the subtle changes in the hardware environment and lock down the computer and say it is not genuine and there is absolutely nothing you can do to make it work normally. And with all of the negative comment I have written about MS in the past couple of weeks, I have to say that this adds further to that viewpoint, as does the rest of this post. I did get that computer working but it was a real mess to have to go through it all again after having sysprepped it and that should not have been necessary, it was totally unnecessary but that is another example of the MS mentality.

The second thing I have been working on lately is Thin PC, the latest effort being to see if it can run a very old software package we have which is called Successmaker 5.5. This package has been around our school pretty well for the last 6 years and we started with it on Windows 98. The installer that comes with it had some trouble on Windows 7 and it wasn’t totally due to lack of elevation, there were some of the things it was doing that just wouldn’t work at all for whatever reason. So I tried another tack. I built up a Windows XP machine and ran Ghost Autoinstaller (AI) on it to capture the machine state, I then installed SM on this machine, ran AI Snapshot again and built an AI installation. Then I went over to the Thin PC machine and ran this installation. I then had to customise some config files and then I tested it and it worked properly. So it looks like we can load up some machines with this version of 7 and have them running this old legacy package.

I then decided to capture the installation with sysprep and this is where I ran into problems. On reboot there was an error during installation, some problem with the product key, and Setup threw a fatal and told me to reboot. Well of course that did not fix the problem at all. This became another unrecoverable setup error like others I have seen before. The only fix is to remove the image and completely replace it. As you would understand this means I have to build the image again from scratch (as my pre sysprep image turned out to be corrupted). It’s becoming abundantly clear that Windows 7 Setup can’t actually recover from many errors and even if MS fixes the problems like this they have bought themselves another bad rep with OEMs and organisations which use imaging.

UPDATE: The one good thing about reimaging the laptop with a sysprep was that all I had to do after setup finished was join it to the domain. It picked up the existing user profiles and settings that were already on the laptop without problems. So it looks like to speed up this process, because I had to repeat nearly all the steps from the beginning to implement the sysprep, that we will just back up the VHD, then sysprep, then image etc. But sysprep would not have been necessary if some idiot at MS had not decided that we will make an image totally unusable instead of giving a user the chance to activate it again. And the same mentality exists when a setup fails and forces you to completely throw away your image and start again.

More problems with Windows 2008-R2-Vista-7 security elevation

Last week I wrote a rant about the changes MS has made due to its security elevation model implemented in 2008/R2/Vista/7. The post covered what is effectively turning the domain administrators group into a lepers colony, by effectively implementing built in and irrevocable Deny permissions to the administrators group on a computer or server.

Today I’ve just discovered another problem – along with the explanation that it is “by design”. This is the issue that when you elevate a process to administrative rights, it loses access to mapped network drives that it would otherwise have access to on your computer. I already knew this happened at command prompt level, but wasn’t prepared for seeing it occur when I tried to elevate a setup process that also happened to be running on a mapped drive. Although the setup process was able to elevate, it couldn’t find the drives including the one it was being run from (LOL). There is a means of working around this problem as described here.

Whilst I don’t regard rants as an effective means of communication it has served to make the point that these changes which MS have implemented in Windows (along with many others in their service model) have, in my opinion, significantly diminished their credibility to be able to claim they have produced a credible, professional grade product suitable for use by large enterprises in all the situations that would reasonably be encountered in large sites, or multiple sites. MS’s response to the increasing competition they face in various levels has not been to produce a better product, but to slash their costs and service levels, and find new ways of stamping out the competition.

!@#$%^ Windows stupid ownership / permissions changes in Vista/Server 2008

This is a response to the above message which zillions of system administrators world wide hate seeing on their server console. These messages were introduced as a new “feature” of Windows Server 2008, along with the changes that cause them. Microsoft arbitrarily brought in different meanings of ownership in Vista/2008 that are different from XP/2003. In Vista/2008 the ownership of a file or folder has precedence over permissions that are assigned to parent folders. For example in a home folders share, where individual users have created their own home folders or have had them created by an automated process, they are automatically the owner of those folders. Even if the administrator has full control over the parent folder this ownership blocks the normal inheritance of permissions. While there may be situations where an administrator should not have access to users’ home folders, this can already be catered for within the existing mechanisms for setting permissions on a parent folder and assigning them to different administrators, rather than imposing a one size fits all solution based on a Big Brother idea of dictating to organisations how to run their own file server in their own organisation.

Now, a solution to this is to change the ownership of all the files and folders in a location. Make the administrators group the owner and that will fix all these problems? Actually, it won’t. The second change which came about in Vista/2008 is that the administrators group in general no longer has the same authority over the server as they used to. Everyone has seen innumerable messages telling you that unless you tell something to run as administrator, the fact you are a member of the administrators group does not actually give you the rights you should normally have to do something. The implication of this for ownership is that changing the ownership to a group actually does not work. Changing the ownership to “administrators” group does not overcome the problem of getting the above message in the slightest. Windows basically will not honour those settings unless the ownership is changed to only one user. This means that a group of administrators cannot administer files because only one individual user account can be the owner of the files at any one time. Likewise you cannot grant other users administrative permissions to a file share because they are blocked by the ownership issue on the files and folders in it.

These features might make sense on a desktop computer used by only one server. They don’t make sense on a server where an administrator has to be able to manage files. For example we have scripted backups using Robocopy. It is common to see “Access denied” messages in the logs from running these scripts, purely on the basis of this arbitrary ownership change.

Why has this happened? MS has come up with the cheapest and simplest for it solution to all their massive security headaches and put these changes in without asking users what they wanted because all that matters is getting the bad publicity about security breaches off the front pages of newspapers. Some way back I wrote a hard headed post about all the ways that Vista lies to users. These faults to some extent were fixed in 7, but not in Vista. The solution, always, fork out more money for a new edition of Windows. A pattern that is becoming more and more common in Windows these days. Customer service has gone out the window.

Here is a thread that details how annoying Windows 7 home users find this functionality

As aside: What happens when you click Yes to the dialog box shown at the top of this thread? Windows automatically assigns you permissions (Read and Execute only) to the folder in question. Windows has to do this even if you are a member of the Administrators group and have already inherited permissions to the folder, and your user account you are logged onto at the moment is a member of that administrators group; in other words, you can’t use a group to manage security permissions for a resource any more unless they are not some of the built in administrative groups. I haven’t quite figured out yet if I can make up my own group of administrators and give them permissions, but so far everyone seems to be tainted by association with the membership of the Administrators group. 

 
By way of more testing I have confirmed that if I give permissions on the folder to individual user accounts then all the permissions work. If I create my own group and make my administrative accounts members of that group and apply permissions for that group, they don’t work. It is like MS has forced a Deny full control by default to the Administrators group. You can have read only access but not full permissions unless those permissions are granted to individual user accounts only.

None of these changes make any sense, nor does Microsoft appear to have any concept of accountability for them.