|
There is a tool "Terminal Service Manger" available in Windows 2k3, does anyone know is there in any tool available in Windows XP like "Terminal Service Manger".
Note: By mistake I have put this question in "General Discussion" Forum, so putting it at this forum and removing it from that forum.
Thanks,
Mushq
|
|
|
|
|
That would be the Remote Desktop
See here for more info[^]
"Shorter of breath,
and one day closer to death." ~Pink Floyd
|
|
|
|
|
Is there any way to do this?
I know you can snapshot the files over, but is there anyway to make it bootable and start its installation procedures?
"Shorter of breath,
and one day closer to death." ~Pink Floyd
|
|
|
|
|
Probably not without access to the tool that was used to create the partition in the first place.
Cheers,
Sebastian
--
"If it was two men, the non-driver would have challenged the driver to simply crash through the gates. The macho image thing, you know." - Marc Clifton
|
|
|
|
|
It pretty simple, it is a bare min. bootable XP partition, with a secondary executable that does the recovery work.
I can't use F10 to boot into the recovery console, but I can run the secondary executable fine with a BartPE disk
I am not afraid of a little nitty Grity work, and the entire partition could fit on a single DVD, I just don't know how to get the Bootloader Code to form a bootable iso image.
Any clue there?
"Shorter of breath,
and one day closer to death." ~Pink Floyd
|
|
|
|
|
Well, in that case, you'll have to master your own WinPE disk (like BartPE) and include the secondary image.
HOWEVER, there is one caveat: If the recovery tool recovers not only the system partition, but the partition table as well, you'll lose any data stored in the former "recovery partition" and more so if you repartitioned the disk.
If I was you, I'd backup my data, do one "recovery", then use Norton Ghost to image the freshly installed system and thus create your own "recovery media".
Everything else seems to much of a hassle...
Cheers,
Sebastian
--
"If it was two men, the non-driver would have challenged the driver to simply crash through the gates. The macho image thing, you know." - Marc Clifton
|
|
|
|
|
I see... It does recover the partition table...
That sounds like my best choice (NG) as of now, thank you
"Shorter of breath,
and one day closer to death." ~Pink Floyd
|
|
|
|
|
I have a strange problem that shows up after I install our software. By "our software" I mean one of my company's products. I'll try to keep this short enough to read and will happily supply any further details.
The product is written in C# targeting .NET 2.0. It consists of three components. Two are installed as Windows services, the third is a WinForm based GUI. Only one of the services is involved in the problem, hereafter referred to as the "Server." The GUI application is the other involved, hereafter referred to as the "Client."
Both the Client and the Server need to use a third party native DLL, which is installed in the System directory (C:\WINDOWS\system32.) We are hoping to use Windows .msi installer packages, which I'm producing using VS2005. The installers register the DLL mentioned as "vsdrfCOMSelfReg" and that seems to work.
The problem comes in if we install both the Server and the Client on the same computer. Normally our customers will have one Server installed and multiple Clients on different machines as you would expect. However it's possible, even likely, that someone will install a Client on the Server machine. That causes the Server to lose its ability to perform the function for which it uses the DLL.
In our previous versions of this product, we used installers built by another tool, Setup Factory 7.0 from Indigo Rose. I have found that if I use SF7 installer for the Client, I don't have the problem. That's our interim solution until I figure out what's the problem with the .msi installer.
Here's what I've tried so far. Remove all components of this product from the machine, and delete anything left behind by the uninstallers (Registry entries, log files, etc.) Take a snapshot of the file system and of the HKLM Registry hive. Run a Client installer. Take another snapshot of the file system and of the HKLM Registry hive. Compare these snapshots to see what files are installed and what's added to the Registry. Remove Client and clean up after uninstall. Repeat procedure with the other Client installer. Compare results from each type of installer.
The SF7 installer puts some files it uses for uninstalling in the installation directory and in C:\WINDOWS. Other than that, no difference. The .msi installer puts a whole bunch of stuff about itself in the Registry. Both install all the expected files and make the same Registry entries regarding registering the DLL.
At long last, the questions:
Any ideas what might be causing this?
What else should I try in order to find the problem?
Any suggestions for work-arounds or solutions?
Why a duck?
BDF
A learned fool is more a fool than an ignorant fool.
-- Moliere
|
|
|
|
|
Have you enabled MSI logging? if not, read how to http://support.microsoft.com/kb/223300[^] then investigate the resulting log files.
Use Systems Internals Process Monitor (or RegMon + FileMon) to record activity at installation and look for any Access Denied and investigate those.
Keep us posted on your progress
modified 1-Aug-19 21:02pm.
|
|
|
|
|
I'll try the MSI logging. I've got Process Monitor, I'll need to look at it more closely to see how to accomplish what you describe.
So far I've not seen anything missing in either the files or Registry, as I assume would be the case if an Access Denied situation arose.
Thank you for the reply, I'll get busy with your suggestions. 
BDF
A learned fool is more a fool than an ignorant fool.
-- Moliere
|
|
|
|
|
After you have created the MSI file, you could use this utility to look at the contents of the MSI to establish if the MSI file has expected contents etc.
Less MSIérables[^]
modified 1-Aug-19 21:02pm.
|
|
|
|
|
Thanks for the link. I downloaded and used it. Didn't find anything other than what I expected to be in the MSI package. It will be a handy tool to have around. Need to make time to look at the source code.
Today I ran the installer with logging on and Process Monitor running. Examined the log file and the Process Monitor data but did not find any errors of note or anything else relevant to the problem.
However Mike Dimmick posted a reply that I believe contains the answer and some possible solutions. It's quite detailed if you're interested. It turns out that two MSI installers installing the same DLL in the same directory is not as straightforward an operation as I had expected.
Thanks again for your help. I learned a lot from the exercise.
BDF
A learned fool is more a fool than an ignorant fool.
-- Moliere
|
|
|
|
|
I looked at Mike's reply, and his MVP status is well earned, and in these forums, his replies are always most excellent. Anyhow, as long as my replies did not push you down unnecessary blind alleys
modified 1-Aug-19 21:02pm.
|
|
|
|
|
Right, I think your problem here is most likely to be that the file has different GUIDs in the different installers.
Windows Installer tracks 'components', not files. It determines whether a component is installed or not by checking the KeyPath of the component - this is the file, registry key, directory or ODBC data source which it uses to determine whether the component is up to date. Visual Studio generates one component per file or registry key.
You can get into serious trouble if the same file is referenced by more than one component GUID on the machine. For each component installed by a product, Windows Installer remembers the key path that the component was installed to. When the number of references for a component in a given location drops to zero (the actual references are recorded, not the count, so it's more like GC than reference counting), all the resources for that component are removed, even if another component is still referencing the resource.
To avoid this problem, you must either: install the component privately, or if that isn't possible, ensure that the same GUID is used in both products.
I believe the only way to get VS to do this is to build a merge module containing the shared component, and consume that merge module in both installers.
Now for some more fun: although you've told it to self-register at install time, Visual Studio also tries to extract the registry information at install package build time, and uses the extracted data to populate the Class table[^] and the other associate COM tables. This causes Windows Installer to generate special registry entries when installing the class, an extra load of gibberish in a REG_MULTI_SZ value called LocalServer32 in the LocalServer32 key. This data tells Windows to give Windows Installer control when the object is created; Windows Installer checks whether the component is installed and if it needs to be repaired. If so you'll get a repair dialog. If the version numbers are different between client and server, this may happen; if it can't find the original installer, it may prompt for source.
Again, I think this can be reduced by ensuring the GUIDs are the same.
If you don't need to support Windows Installer's enterprise features, it may be easier all around if you use a tool that does not build Windows Installer databases. It's much much harder to make an MSI that works properly when deployed through Group Policy/Active Directory anyway.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Thank you so much for that detailed reply. As this is not our most pressing issue and we have an interim solution, I'll be waiting until my new book arrives in the mail before exploring further.
I'd like to attempt the merge module approach, which I'll try after studying the book a bit. I thought it would be better to have MSI installers but it might be more trouble than it's worth. It's always nice to have options though.
Thanks again, Mike. Once again I'm humbled by how much I don't know.
BDF
A learned fool is more a fool than an ignorant fool.
-- Moliere
|
|
|
|
|
Big Daddy Farang wrote: I thought it would be better to have MSI installers but it might be more trouble than it's worth.
That's been my experience with MSI as well. Lots of headaches for zero benefit. I will never use it for a project if I have a say in the matter.
|
|
|
|
|
Hi
I am a Software tester and need to write test cases for testing MSagent.
I have written a few like opening MS office applications and playing with the office assistant, downloading new characters, opening websites that use MSagent.
Any other innovative ideas on how to test the technology would be of great help.
Regards
Srinivas
|
|
|
|
|
I am writing a C# program to return the permissions of a reg key passed in to the program. i have the main registry part working with one exception when I try to read a key that has a space in the path I get a null exception that is not caught by my error handleing.
issue 1:
RegistryKey
regkey = Registry.LocalMachine;
regKey = regKey.OpenSubKey("Software");
regKey = regkey.openSubKey("Adobe");
regkey = regKey.OpenSubKey("Adobe Reader");
try
{
RegistrySecurity regSecurity = regKey.GetAccessControl();
}
catch (argumentNullException e)
{
Console.WriteLine("Error", e);
}
Issue 2:
why does my try/catch not catch the error?
Thanks
Rob
|
|
|
|
|
I'd post this into the C#-Forum.
Cheers,
Sebastian
--
"If it was two men, the non-driver would have challenged the driver to simply crash through the gates. The macho image thing, you know." - Marc Clifton
|
|
|
|
|
Hi,
Why would I get an:
'regsvr32' is not recognized as an internal or external command, operable program or batch file.
TIA.
----------------------------------------------------------
Every nation state's armed forces call themselves 'Defence',
makes me wonder why there are conflicts in the world.
|
|
|
|
|
Hi,
works on my Vista system.
regsvr32.exe is located in C:\Windows\system32
|
|
|
|
|
Works fine here, not sure why in your case it isn't coming up.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
We have a windows service which spawns a browser.
To enable this operation,the service has been configured to "Interact with Desktop",runig as localsystem account.
This does the desired,in most of the windows environments(2000,XP,2003).
However,in some of the Windows 2003 boxes(not all),we find no visible browser instance.
However,we have confirmed that the browser is indeed spawned under the 'SYSTEM' account through the task manager.
This confirms that there is no problem in the execution of the executable as such.
We have explicitly set the 'visible' property of the IE browser handle to 'true'.
Is there some security setting/configuration that may potentially have been flagged to suppress the 'visibility' of the browser in these specific 2003 hosts?
Any help on finding the source of this 'invisibility' of the browser will be much appreciated.
Note:This happens only when the browser is spawned from a service.When spwned from command line(interactive),things work fine even in these particular hosts.
|
|
|
|
|
We've found that it can take a system reboot before the interactivity of a newly-installed service starts working.
In addition, this only works if you're logged in on the console session (session 0). For Remote Desktop/Terminal Services, run mstsc /console.
You should move away from this approach ASAP as Windows Vista and Windows Server 2008 have locked down session 0: you can no longer spawn processes that will appear on the user's desktop.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Thanks.
One clarification - what is the option to do a similar operation on widows vista/2008 server?
If we impersonate a logged-on user,though we do not see the browser,it serves the purpose for us.
Will impersonating a interactvie user for a process launched from a windows service continue to work in vista/2008?
Or will that be clamped on too?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
