|
Mike,
Thanks for the prompt reply.
Even the built-in admin account is kicked out from the Administrators group.
In other words, there is no account in the Local Administrators group on this box 
|
|
|
|
|
neualex wrote: Even the built-in admin account is kicked out from the Administrators group.
That's impossible. You cannot remove the built-in Admin account from the Administrators group.
|
|
|
|
|
Dave,
You are right, the administrator account is not removed from the Administrators group.
The problem is that the account is disabled , and there is no other account with admin rights to enable it. Power user cannot do it.
Is there still hope?
|
|
|
|
|
|
Dave,
Thanks for the post.
However, let me remind you that only one admin account exists on this XP box, and it is disabled.
The post explains how I can reset the password, but not how to enable it back.
If I miss something, please let me know.
Thanks again,
neualex 
|
|
|
|
|
I know. There is a CD image on that site. Burn the CD, boot the machine on it (it's a Linux boot!) and it'll let you reset the password AND re-enable the account.
|
|
|
|
|
Hi folks. I'm hoping someone can tell me the metric Windows Installer uses to determine if an existing instance of an application is installed on a system, because I changed a bunch of settings for my setup project and now when it's installed over an existing copy, I get two entries in the Add/Remove Programs control panel. It was working before.
Some notes:
-Both apps install to the same directory and include 99% the same file names.
-Both have the same version as encoded to the installer (diff assembly versions, mind).
-The ProductCode is changed for every update, but I've been doing this all along with no probs.
What can I do to prevent this duplicate entry from occurring? It's a real problem because they cannot both be "uninstalled" as they're using the same files!
Thanks in advance,
Logan
{o,o}.oO( Did somebody say “mouse”? )
|)””’)
-”-”-
|
|
|
|
|
They should both be able to be uninstalled. Windows Installer reference counts installed components and does not remove files until they are no longer referenced by any installed product. It tracks installed components on a per-directory basis - it can cope with the same component being installed in multiple directories and removes each separate install location when that location is no longer referenced. (It doesn't actually count - it records which products have installed which components in which directory).
Note that file versioning rules exist. If a file has a version number in its resources (typically only EXEs and DLLs), the file with the greater version number wins. If only the new file has a version number, that will overwrite an existing file without a version. If neither file has a version number, the incoming file always overwrites the existing one, unless it has been edited (its modified timestamp is different from its creation timestamp - Windows Installer sets the creation timestamp and modified timestamp the same when installing the file). Registry entries are always overwritten. The net effect is that when you uninstall the new product, the newer files are actually left behind, you are not prompted to reinstall or repair the old one.
You can get into trouble if you have multiple components which install the same file to the same location, because Windows Installer will no longer have accurate reference counts. See Rob Mensching's (creator of WiX) blog post "Component Rules 101"[^] for more on this. However, if you're merely modifying the same installer project, Visual Studio will keep the same component identifier GUIDs for the same files (this may not be correct, if your resources are not in fact compatible across multiple versions, and VS has no way to allow you to change a GUID, except by removing and replacing the file).
Changing the Product Code is absolutely correct for a major upgrade. Visual Studio does not offer much assistance for minor upgrades, so you should really stick to major upgrades. You should always change the Package Code for any new build of your package.
Windows Installer detects families of products using the Upgrade Code. This GUID should be kept the same across all versions of your product until you want to break the family association. Windows Installer itself supports detecting any number of Upgrade Codes, optionally removing them before or after installing the new product, but Visual Studio does not allow them to be specified, specifying only the UpgradeCode from the current package.
In VS, you control what happens using the RemovePreviousVersions and DetectNewerInstalledVersion properties. You cannot choose when the RemoveExistingProducts action is scheduled; it's always scheduled after InstallInitialize. That means that if the new installer fails, the old product is reinstalled, and the old components are removed before adding the new ones. This is a pretty safe choice.
You've probably either changed the UpgradeCode or one of those two properties. I would leave them both set to True unless you really want side-by-side installations.
Windows Installer is much more complicated than it initially seems and in my opinion, has no business in a dumbed-down developer tool like Visual Studio. At least, not in this dumbed-down form. If you're going to use it I strongly recommend getting the book "The Definitive Guide to Windows Installer" by Phil Wilson, from Apress.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Wow thanks a ton for the detailed response. Based on your description, I am betting it's the UpgradeCode, since I do remember changing that. I was under the impression that ProductCode was logically superior to UpgradeCode (based simply on their names), thinking that changing UpgradeCode would have no effect if I was also changing ProductCode. Apparently this is not correct at all! They should have called UpgradeCode FamilyCode or something to that effect.
Now I have to figure out what the previous UpgradeCode was so I can restore it! :P
Also I believe I was having trouble uninstalling both due to the fact that both "products" (really just one, hence the problem) use installer services to perform uninstall actions.
Windows Installer sure is complicated. If I decide to continue working with it I will most definitely check out that book on your recommendation. That said, however, are there any other third-party installation tools you would recommend over Windows Installer?
Aha, found the UpgradeCode using Orca to look into my older installer.
Thanks for the reply. This has undoubtedly saved me a lot of headaches.
{o,o}.oO( Did somebody say “mouse”? )
|)””’)
-”-”-
|
|
|
|
|
What linux commands which use to get file size(ContentLength) of target url such as "http://www.xxx.com/pic.zip"?
thank
|
|
|
|
|
Try asking in a linux forum.
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
Anyone using Powershell yet?
Like it?
“If we are all in agreement on the decision - then I propose we postpone further discussion of this matter until our next meeting to give ourselves time to develop disagreement and perhaps gain some understanding of what the decision is all about.”-Alfred P. Sloan
|
|
|
|
|
|
Yes, "I be meaning that". You use it? Like it?
“If we are all in agreement on the decision - then I propose we postpone further discussion of this matter until our next meeting to give ourselves time to develop disagreement and perhaps gain some understanding of what the decision is all about.”-Alfred P. Sloan
|
|
|
|
|
My contact in Microsoft Exchange Support calls it 'PowerHell'.
This may however simply be that some operations that could be done through the GUI in Exchange Server 2003 can only be done through cmdlets in 2007. Basically Microsoft rewrote the whole management interface for 2007 in .NET 2.0 in order to use PowerShell and Microsoft Management Console 3.0 (which allows .NET snap-ins without COM Interop), but all of those technologies were delayed and they didn't finish the GUI bits in time for RTM.
Apparently more GUI features are coming in SP1. Still too soon for us, though - Exchange Server 2007 requires x64 and we can't afford to dedicate a box solely to Exchange, so our newly installed servers (about a month old) run the 32-bit OS and Exchange Server 2003.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Hi
Can any one explain me with example
Regards,
Sivaprasad
|
|
|
|
|
Application Programming Interface...
This is a better explanation than any I could do for you[^]
“If we are all in agreement on the decision - then I propose we postpone further discussion of this matter until our next meeting to give ourselves time to develop disagreement and perhaps gain some understanding of what the decision is all about.”-Alfred P. Sloan
|
|
|
|
|
Does anyone know an easy way to get rid of the startup boot message that asks you which OS? The boot thing is fedora grub
|
|
|
|
|
You could set timeout value to 0. It won't eliminate it but the boot won't pause.
Judy
|
|
|
|
|
The problem is that it boots into fedora by default and I need to boot into windows
|
|
|
|
|
I propose you boot into fedora and change the config files; make windows default and then set the timeout to 0secs, will automatically boot into windows.
---------------------------
Both optimists and pessimists are important in technology. The optimist invented the aeroplane; the pessimist invented the parachute.
Regards,
Hesbon Ongira
Nairobi, Kenya.
|
|
|
|
|
Reset the Master Boot Record. I think fdisk /mbr does the trick.
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
Paul Conrad wrote: fdisk /mbr
If memory serves, do same if you have a mbr virus that "ordinary" anti-virus applications can't resolve.
modified 1-Aug-19 21:02pm.
|
|
|
|
|
Actually you shouldn't do this, because some of the MBR viruses actually encrypt the hard disk contents and wiping the MBR also overwrites the decryption key.
That said, most of these aren't compatible with Windows NT/2000/XP/2003/Vista because the decryption is done through the 16-bit BIOS interrupt handlers and the 32-bit device drivers won't chain through the code installed by the MBR.
And of course if you are using XP, you should boot from the setup CD, go into the recovery console, and run fixmbr, because the Windows 9x/DOS MBR doesn't know how to boot Windows.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
i am a computer science student in BITS-Pilani. We needto manipulate an existing dos program as my assignment. suggest me what should i read in particular and how to proceed.
thank you.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
