Jump to content

Escorpiom

Members
  • Posts

    46
  • Joined

  • Last visited

Everything posted by Escorpiom

  1. App = IDM itself. For example, installing IDM and rebooting, it is not starting. It should do so to be able to intercept downloadable stuff. Instead, it is needed to manually execute IDM, choose the language and only then it will be running. Desired behavior would be that the language is set at setup (system language) and that it starts automatically after a reboot. Cheers.
  2. - Damaged browser integration popup still showing, might be related to having Opera installed - No autostart after install - Executing app the first time triggers language selection (should have been handled by the install script) Cheers.
  3. StopLooking, This works only for the English version on an English language OS. Any other language you probably have to change some windows id's and button names. The script may be adapted for a specific language and as such it can be useful. Cheers.
  4. Well, this is getting interesting :-) Thanks for your dedication niterider, I'll test it asap. Cheers.
  5. Sorry mate, I don't use your repack anymore, without working browser integration it makes no sense installing. The related error at every reboot is also annoying. Sadly I haven't got the time to debug the script, but if you fix it in the future I'm happy to test it. Cheers.
  6. Hi rick, are you still working on this tweaked Skype? Cheers.
  7. You don't understand. Why do you fiddle around with uniextract? If you had followed the two relevant topics here, you would have known that it has been made with Inno. Furthermore, this installer appears to be packed with a non-vanilla Innosetup packer, cannot be extracted by means of uniextract or better said innounp. If the author of the repack makes available his sources to you is another thing. Cheers.
  8. Hold your horses lads. IDM is not easy to do, there are several issues that needs to be resolved but consider it work in progress. I really don't think anyone gets it perfect the first time. So lets instead give some feedback about what does and what doesn't work. And yes, it's Inno. Cheers.
  9. I've just tested the new build. Basically it works, I haven't had time to check reg info yet, but I did see that browser integration is still broken. You've attempted to create a reg key for Chrome integration, but failed to take into account the registry redirection on x64 systems. As inno is a 32 bits setup, registry redirection is already being done. As you've added the "wow6432" node to your script for x64 OS, this in fact gets duplicated in the registry. For example: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Wow6432Node\ I haven't had the time to digg deeper, and I don't know if that is the cause of non-working browser integration. But your IDM setup is currently unusable because of this, every reboot an error is being displayed also. Can you try to fix that please? Cheers.
  10. Just did another run with the previous IDM sfx. As you can see it is registered, although not legally. I think something got embedded, maybe using a retail installer. Next up is to test your new sfx. I'll update asap. Cheers. Edit: Main issue with the old package is the browser integration (left unconfigured). At each boot idm shows an error complaining about broken browser integration. If you can fix this (perhaps already in new build?) then the sfx will work ok.
  11. No big deal, I'll upload the screencap when I give it another run. I've got no idea where that name came from. As said, it was a clean install. Maybe it's not in the inno script but embedded somewhere. Anyway it's a good job, IDM was not easy to do at all and you've made my computing life a lot easier. Cheers.
  12. Awesome! Will do more tests soon. The reg info shows it is set to "Muhammad" or some guy...This is a totally clean 8.1 install, so something is going on. I found that the installer can not be named like "idman" because at install it complains about running processes. Cheers.
  13. Can you update? Build 19 has been released. Also, I think you have by mistake included reg info... It is not completely silent, but as you use inno, it wouldn't be so hard to make it totally silent. Maybe browser integration can be fixed, as it broken after install. Thanks for your work. Cheers.
  14. I'll eat all the cookies they want, but still cannot download...The same message as reported by bphlpt: "Please enable Cookies in your browser." Earning a couple of bucks is OK, but the service provided simply does not work - and it is not the first time. Thanks for the update anyway. Cheers.
  15. Fecha publicada: 07/06/2011 I´m confused about the date... Cheers.
  16. @myselfidem: I'm well aware of that, I already mentioned it in my previous post that this was not recommended by MS - however, we need this setting. If we specify most settings that would otherwise be done by MachineOOBE in the answer file there is no problem.
  17. Here is the regkey I'm using to check for a double firstlogon-run: REG QUERY "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\PostInstall" /V "FirstLogonRan" >NUL 2>&1 && exit REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\PostInstall" /V "FirstLogonRan" /T REG_DWORD /D "1" /F >NUL 2>&1 Not tested yet, but it should work. I chose this reg key because it seems that it will not be redirected on x64. Adding should not be a problem, firstlogon runs as admin. @myselfidem: Your autounattend.xml has only the x86 WinPE pass, not the x64. Is it not needed? Cheers.
  18. Well, perhaps the method crashfly suggested is the most convenient, in my case I'd rather have one batch only instead of two. Going to do some tests. In the same way you can also set a reg key and check it when the batch runs, for example REG QUERY , if exist "key" then exit REG ADD "key" Or something similar, nothing will be written to disk. Perhaps the RunOnceEx key if we are using it? The method bphlpt explained is working perfect also, tested it yesterday. Thanks for the effort. Ah, almost forgot, my batch will add some reg entries, after that it searches for a network share, if not found it searches for a local source. If a source is found, it sets the post install source as a drive letter. On that source drive is an universal ROE batch that adds the RunOnceEx entries to the registry. After that it is executed. At the end a little cleanup and a reboot. So: Autounattend > Firstlogon.cmd > ROE.cmd. Where the Firstlogon is always on the systemdrive, the ROE batch can be anywhere. Cheers.
  19. In that case the only setting left for a DVD install is the Windows version to install. There is a file on the dvd that defines the windows version "ei.cfg" but probably, if the Autounattend file is present ei.cfg will be ignored (not sure about that) So that would require to set the Windows version in the Autounattend.xml, making it not universal. Everyone has his or her way, as said before I'm using a modified NT6Fast installer, the advantage is that it skips the WinPE pass. ImageX will extract the wim index I choose to the harddisk, create boot menu and bootsector and copies the autounattend file to the windows\panther folder and firstlogon.cmd to c:\install folder. That takes about 4 or 5 minutes, only when rebooting the autounattend.xml will get used. This method is universal for all editions, both x86 and x64. On a side note, I modified the NT6Fast installer to do the partitioning and have included a XP universal .wim image, so I have only one script that can deploy many OS the unattended way. bphlpt, did you look at the test batches I made? Did I get it right this time? Cheers.
  20. Yes, but when using a blank password you can take out this: <AutoLogon> <Enabled>true</Enabled> <Username>Paul</Username> </AutoLogon> And you could add these in OOBE: <ProtectYourPC>3</ProtectYourPC> <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE> In other words, setting "skipmachineoobe" to true does not mean these setting will be skipped, they will be processed. Everything else looks great! Cheers.
  21. You're right, it is confusing. I just made two batches on my x86 system to test te output. Sometimes I have to make it a bit more "visual" to understand it, this time I got it. @echo off if not exist "%SystemRoot%\SysWOW64\cmd.exe" (if not defined PROCESSOR_ARCHITEW6432 set Arch0=x86 && goto :Cpu86) goto :exit :Cpu86 echo this is for x86 OS. pause exit :exit echo this would be a 64 bit OS and exits. pause exit This correctly returns that it is for x86 OS. @echo off if exist "%SystemRoot%\SysWOW64\cmd.exe" (if defined PROCESSOR_ARCHITEW6432 set Arch0=x86 && goto :Cpu86) goto :exit :Cpu86 echo this is for x86 OS. pause exit :exit echo this would be a 64 bit OS and exits. pause exit When taking the "not" out, it returns 64 bit OS. This is only to test the statement, and the output is correct. It is indeed the best way to deal with the issue. Some other things I noticed: - the autologon count 999999 setting is not needed if you use a blank password, I created a user account "User" and no password, and was logged on. - For a random computername you can use a * - If you don't want to use a key, it is possible to set "skipmachineoobe" to "true". I know it is not recommended by Microsoft but it allows me to install any Windows edition with one Autounattend file while retaining the 30 days trial period. It is necessary to specify the other parameters like user account creation and such. Note that this doesn't work for DVD installation method, as you need to choose the Windows version. - Disabling UAC from the Autounattend.xml didn't work, I had to put some registry settings in firstlogon.cmd. I guess it has to do with the "offlineservicing" setting, as I use another installation method (NT6FastInstaller) this would not be "offline". Cheers.
  22. Ah! Now I understand. I looked carefully at the post myselfidem referred to, and this is my conclusion: I'll make two different files, one firstlog_x86.cmd and another firstlog_x64.cmd. To the firstlog_x86.cmd I'll add this: if exist "%SystemRoot%\SysWOW64\cmd.exe" if defined PROCESSOR_ARCHITEW6432 goto :exit Or, in other words, if the x86 batch is run on x64 OS, it will just exit so only the x64 batch runs. If this works you two are my heroes. If I got it wrong, you may hit me for being stupid. :-) Will test it as soon as possible. Cheers.
  23. Hello all, I've made an Autounattend.xml for both x86 and amd64. On x86 based systems it works perfect, but on x64 the earlier discussed problem with firstlogon.cmd appears. I have set the command in the oobeSystem pass, and there is a section for both x86 and x64. My firstlogon.cmd is the same for both x86 and x64, as it basically sets the RunOnceEx registry entries to do post install tasks. In fact, the problem is that firstlogon.cmd executes twice, and that causes two separate RunOnceEx processes that do in fact the same thing. This of course breaks the whole post install routine on x64 systems. From reading this topic I understand it is because in x64 setup, the x86 section is also processed. I understand what is happening, why it is happening but now, what would be the best way to deal with it? - Just delete the firstlogon.cm instruction from the x64 section so it will only be processed once, by the x86 section; - Move the x64 component before the x86 component; - Maintain two unattended.xml files. Over at MSFN I saw that bphlpt asked the same question, http://www.msfn.org/board/topic/139572-ask-your-seven-xml-here/page__view__findpost__p__998530 he was referred to this thread but I only got more confused, because how about the other things like user account creation, will that also run twice? I hope people can share their views on this issue. Cheers.
  24. Yep, I was hoping to keep the GUI but reading Rick's reply here it seems that it isn't possible. So I'll just repack it with the "all" module and skip the nice interface. Cheers.
×
×
  • Create New...