jaclaz

Read here (examples) about setting up a "mail server": http://smallbusiness.chron.com/create-smtp-server-computer-51563.html http://www.techrepublic.com/article/get-it-done-host-your-own-e-mail-server/ Then, simply FORGET ABOUT THE WHOLE IDEA https://www.digitalocean.com/community/tutorials/why-you-may-not-want-to-run-your-own-mail-server http://blog.online-domain-tools.com/2015/02/09/how-to-setup-your-own-mail-server-that-will-deliver/ I don't want to scare you away or put you down in any way , rest assured, but properly configuring a mail server is not something you can learn from a few answers on a forum, or from one or two (nice as much as they can) articles here and there, you will need to study the matter and make a lot of experiments (and not necessarily the result will actually be "properly configured" ). See here: http://www.vsysad.com/2012/04/setup-and-configure-smtp-server-on-windows-server-2008-r2/ what the "SMTP feature" can do (mail relay, as opposed to "real" mail server). Maybe this older article/PDF better clears the concept of "outgoing mail server" or "relay mail": http://www.outlookwise.com/Downloads/Documents/OutlookWise/OutlookWise_SMTP_Mail_Server.pdf jaclaz

Sure , I was implying that I was talking of "common devices", i.e. devices commonly in the hands of a common final user, i.e. PC's and laptops, of course NOT POS' or "Embedded devices", this all in all restricts the amount of devices with 32 bit UEFI to a bunch of lowish-end tablets and possibly computers-on-a-stick or similar devices. jaclaz

The news are that the good MS guys, at the scope of simplifying the PUR (Product Use Rights), made it "monolythic" with "Product List" creating a monster now called "Product Terms": https://www.microsoft.com/en-us/Licensing/product-licensing/products.aspx I believe that the same people (roughly 90% of the - maybe - 10% users that actually read this kind of things) that completely failed to understand the previous PUR will have now the possibility of continuing to fail to understand anything, but only after having spent some additional time. jaclaz

Well, with all due respect , it seems to me like you are still mixing a lot of stuff together, and having a possibly a little bit too ambitious scope.. An 8/8.1 OS can boot from a machine that has: BIOSUEFI CSM (please read as emulated BIOS)UEFI The above has very little to do with the used partitioning scheme, BUT: BIOS->MBRUEFI CSM->MBRUEFI ->GPT AND: BIOS (32 bit architecture) -> 32 bit OSBIOS (64 bit architecture) -> 32 bit and 64 bit OSUEFI (32 bit architecture - RARE) -> 32 bit OS ONLYUEFI (64 bit architecture - common) -> 64 bit OS only There is an ongoing topic on reboot.pro (where you posted this same question) about making a GPT disk being bootable in BIOS from a GPT disk (in such a way that the same disk, unmodified, can boot on UEFI also, i.e. work with both firmwares), as I see it this is the least of the possible problems. Set aside (for one moment[1]) the vhd stuff (which is - right now - a complication and not a simplification) and the use of .wim as intermediate passage (which is also - right now - a complication and not a simplification), answer these questions: Which bit width is the involved OS? Which bit width is the involved hardware? <- as a "final user" you should have a fair idea on the machines involved How many devices are involved in the process? How different (in hardware) are they? Which storage media (USB, internal or external hard disk, internal or external SSD, etc.) do you plan to use? How big in size (uncompressed) is the OS (including apps, data, whatever) that you plan to "migrate"? (or if you prefer how big in size would you plan your - at the moment only hoped for - .vhd?) Consider also that if you are a "private" "final user", you simply have no (AFAIK) access (legally) to an Enterprise release/license. jaclaz [1] i.e. until it will be determined that it represents your "best option".

However, the cat in the picture, though surely unharmed, seems like not being particularly pleased/amused about the (even if only temporarily until the new cover was fitted) ban from the nice, cosy, warm place it found. jaclaz

Well I believe that the good guys at MS (the technical ones) know much more and better than me, the end product that you can (will) see has very little to do with them but a lot with management and marketing (without forgetting the legal department ) . Set aside the known issues (which are by design) specifically it seems like they are going to remove the WOF/WIMBOOT mechanism (which I see as an exceptionally good feature for PE's and more generally for "standard deployment" of simple machines) maybe they will keep it as an option in some Embedded version but they are going to remove it from main because it clearly conflicts with the "continuous update" model, in a nutshell the WOF was intended for use in the stupidly underpowered (and with senselessly limited in size mass storage devices) tablets in order to leave some storage available to the customer even running the crazy amount of bloat that the OS is, but since the updates do not go "inside" the .wim this approach works very well until you start pushing updates (and large ones, while we are at it) continuously as the advantage of the compressed OS are soon overtaken by the non-compressed updated files, the matter was discussed here (for the interest of the OP): http://www.msfn.org/board/topic/173786-whats-up-with-the-bevy-of-optional-windows-81-updates/ To be fair the theories behind both the WOF/WIMBOOT mechanism and the one that is going to replace it (or maybe only alongside with it): https://www.thurrott.com/windows/windows-10/2062/microsoft-explains-os-compression-in-windows-10 are - with all due respect to the good guys at MS - not entirely new, a few people here may well have being familiar at the time with all the nonsense about Stacker/Doublespace/Drivespace in good ol' MS-DOS times and a number of other peeps will have experience with attempts to UPX all (or as much as possible) executables in a Windows OS. Nothing new under the sun, though the WOF/WIMBOOT has been implemented very nicely and there is no reason to suspect that OS compression in Windows 10 will not be as well working fine, the point is that instead of building a bloated OS and then compress it, it would have been IMHO smarter to build a lean OS and then leave it alone (or compress it to gain further *whatever*, be it speed, available storage space, etc.). jaclaz

You are welcome , glad to have contributed to (yet another) happy bunny. http://www.msfn.org/board/topic/128727-cant-access-repair-my-pc-option-via-f8-startup/?p=828512 jaclaz

...and ? jaclaz

More generally, a .WIM is an image of the contents of a filesystem and it is applied to a volume, and a volume can exist on both MBR and GPT (and for that matters the same volume can be addressed through both). If you prefer the MBR vs. GPT is about partitioning structures, the volumes (and filesystems on them) have not changed one bit. As well, the .wim is a nice format because of it's high compression, but it's not essentially much different from a "normal" backup made through <insert here your preferred tool> archiving filesystem contents in the <purt here your preferred compressed format> format. The new (nice) technology introduced in 8.1 is (was) the WOF driver, that allows to boot from a .WIM image directly, the fact that it was introduced for the "wrong" reasons and it is now going to be removed in 10, for other, different but still "wrong" reasons is another story. Maybe the stupid Windows 10 will have an even better approach to compressed "bootable" or "live" filesystems . jaclaz

I don't know, maybe I am too simple minded, but what would you think if you found a file: <drive letter>\Users\[username]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\6To_60S7K_FU06yjEhjh5dpFw96549UU\scout.exe And after deleting it, it comes back at next boot? UNless of course some sophisticated techniques were used to make *somehow* the file super-hidden: http://blog.trendmicro.com/trendlabs-security-intelligence/hacking-team-uses-uefi-bios-rootkit-to-keep-rcs-9-agent-in-target-systems/ jaclaz

The reference cable is most probably to standard A connector (the "normal" USB connector on motherboards) and the standard mini-B connector (usually on external boxes ther staandard-B is used, lately on small boxes such as those for 2.5" disks it is replaced with the mini-B ), the micro-B is AFAIK/AFAICR only used in smartphones/tablets and similar: https://en.wikipedia.org/wiki/USB https://en.wikipedia.org/wiki/USB#/media/File:Usb_connectors.JPG jaclaz

Another sign that the end of the world is near http://www.citylab.com/tech/2015/07/when-you-give-a-tree-an-email-address/398219/ jaclaz

In other places things are not going well : http://dustri.org/b/firefox-youre-supposed-to-be-in-my-pocket-not-the-other-way-around.html http://www.ghacks.net/2015/06/23/pro-and-con-of-mozillas-pocket-integration-in-firefox/ It seems like the "your privacy has no relevance for us" mantra is spreading jaclaz

My bet is on a 0x0000007b due to your having attempted to install on a SATA disk in SATA mode but failing to provide the right drivers. That is FAQ #3: http://www.msfn.org/board/topic/116766-faqs/ but it is possible, since you mentioned nlite, that you overdid it a little (and that would 0x0000006F and FAQ #2). Don't worry, it's normal, everyone has had the one or the other STOP error. Depending on the motherboard, you might find this useful: http://www.msfn.org/board/topic/107504-integration-of-intels-sata-ahci-and-raid-drivers/ jaclaz

OT, it had to happen sooner or later: http://creativity-online.com/work/toyota-a-sirious-safety-message/42660 with a good scope and all, but all in all not much different from the prank I expected: http://www.msfn.org/board/topic/173316-windows-10-prediction-and-os-ranking/#entry1092785 jaclaz

From what you report you have a "generic" issue in booting from USB (which would be the first thing to check/fix). Forget about Xboot, its Author was a victim of a road accident and the tool is not developed since his premature death. Both WinSetupFromUSB and Rufus are actively maintained, both of them boot normally on - say - 99.99% of machines, and since they use different booting code/method it is "queer" that none works in your setup. Forget (temporarily) about both mentioned tools and about your project involving windows 7 and XP and concentrate first on having a grub4dos booting from USB on your system, one way or the other. Try using RMPREPUSB: http://www.rmprepusb.com/home/quick-start-guide You want to have NTFS and Boot as HDD C: 2Ptns selected than try any of: WinPE V2 ... etc XP Bartpe and (this is the option that you essentially want to succeed with) try the "install grub4dos" button. Once you have managed to setup it so that it boots to *something* be it grub4dos, NTLDR or BOOTMGR (i.e. you are past the "blinking cursor") will talk of the rest. That "blinking" cursor is typical of a mismatch between CHS and LBA or of a wrong geometry in the standard NTFS bootsectors. If you cannot manage to make the stupid sticks to boot, make a copy of both the MBR (first sector of the disk or \\.\Physical drive) and of the bootsector/PBR (first 16 sectors of the \\.\logical drive, i.e. what gets a drive letter in Windows), compress them in to a .zip archive and attach the archive to a post and I'll have a look at them. Hdhacker is a suitable tool to make such backup copies: http://dimio.altervista.org/eng/ jaclaz

Hmmm. This piece of advice was vane. http://www.msfn.org/board/topic/174072-capturing-a-windows-xp-reference-image-after-sysprep/?p=1102569 jaclaz

Oh, yes it is perfectly possible (given links in post #2). jaclaz

There must be a communication problem of some kind. If you deploy a windows XP a C:\install folder is ALREADY in the source and it is deployed just like the rest of the system. If you install a Windows XP a C:\install folder may be created as part of the install or post-install procedure. http://unattended.msfn.org/unattended.xp/ http://unattended.msfn.org/unattended.xp/view/web/63/ jaclaz

Yep, this is what I tried to explain to you that an .iso cannot be. Such a .iso is more simply an updated .iso, with added (say) Drivers Packs and maybe even third party programs with (possibly) some unattended scripts and even (maybe) a WPI (Windows Post Install Wizard). The difference is that the .iso remains a "setup" (and NOT a sysprepped image), the OS is installed from the .iso source while in the case of the sysprepped image the image is deployed and then only minor adjustments are made. Everyone will have it's own saying on which one is a "better" approach, and everyone will have his/her own lkes and dislikes, a whole series of other "mixed mode" approaches are possible, but you have to first convince yourself that "install" is different from "deploy" and "sysprep". The rule of the thumb is that if the source (be it a .iso or whatever other format) has a "main" \i386 directory it is an "install", if it has a "main" \Windows directory it is a "deploy" (of a sysprepped or non sysprepped image). jaclaz

It isn't a good idea to name WAREZ on msfn.org, see Rule #1.a: http://www.msfn.org/board/index.php?app=forums&module=extras&section=boardrules not even discussing on how these are created . jaclaz

It is a generic board issue that is recurring and that was fixed and broken and re-fixed and re-broken n times lately, it doesn't affect only you, but the real causes (and correspondent remedies if any) seem like not having being pinned down yet . Check this (where you should have posted about the issue): http://www.msfn.org/board/topic/163472-ipb-update-july-2013-to-version-345-bugs-only/ starting from around page 10: http://www.msfn.org/board/topic/163472-ipb-update-july-2013-to-version-345-bugs-only/page-10 jaclaz

How much? Would a fiver or a pint of beer (whichever comes first) do? Judging from: https://buildfeed.net/ A 10.0.10240.0 (private) was compiled AFTER 10240.16384 (and this should mean something on how well synchronized is the builds numbering mechanism ) , so, not completely surprisingly, build 10.0.10400 could still be a good candidate, and we still have some 2 full weeks before the deadline.... jaclaz

Well, you are seemingly "mixing together" two different deployment methods. The "normal" XP install starts from a .iso which is normally "attended" and the setup can be made "unattended" or if you prefer answers to the questions asked during the setup phases can be pre-written. What actually boots the first time is a sort of "recovery console", and what boots after the so-called text setup phase is the actual OS in not-configured state from the internal hard disk. Starting from the new "paradigm" of .wim, since Vista, the install is actually the applying to the disk partition/volume of a pre-made sysprepped image, of course "generalized", hence the possibility to "install" a Vista or 7 (or later) by simply applying the .wim, without any real *need* to run setup.exe, see: http://reboot.pro/topic/10126-nt-6x-fast-installer-install-win7-directly-to-usb-external-drive/ So what you could use is either the Offline Sysprep: http://www.911cd.net/forums//index.php?showforum=43 http://www.911cd.net/forums//index.php?showtopic=19397 Then transfer the hard disk partition image with whatever tool you see fit or are familiar with or capture it as an XP .wim (you will need some files from Windows 7 or later), some ideas are here: http://www.911cd.net/forums//index.php?showtopic=25716 Basically the idea is to create a sysprepped image, capture it as a .wim, then apply it to the target from a PE not unlike the way Fujianabc detailed for Vista/7, the real issue with XP sources are of course the HAL/Kernel changes and mass storage devices (unless you need this for a specific given machine). Depending on the actual use you may have restrictions preventing you from using this particular approach: http://reboot.pro/topic/4729-panther-xp2003-deployment-system/ http://thuun.boot-land.net/PantherXP/ which is more or less derived from the way the lesser known WINFLP edition install, a low-resources needed version of Windows XP for some markets, that was the first example of deploying XP through a (primitive and using an actually different format) .wim. I hope that I have not confused you too much , only trying to give you some ideas and references to "previous art" . jaclaz

You see , you are NO better than my friends and colleagues, your first second thought was about a possible way to make the thing into a prank. jaclaz