jaclaz

Sure , that's pretty much "expected" and "normal" (though it is what is usually called a fraud, you pay money someone for something that is NOT done), the news are that ADDITIONALLY those data that were not deleted were also poorly protected. jaclaz

on a - let's say with possibly delicate implications - web service/club : http://arstechnica.com/business/2014/08/cheaters-hook-up-site-ashley-madison-makes-account-deletion-confusing/ but it later comes out that not only it was not actually deleted , but the data was actually stolen? http://krebsonsecurity.com/2015/07/online-cheating-site-ashleymadison-hacked/ jaclaz

Well, it's not the fault of the technicians, as always the issue is the marketing and management that are too short sighted to understand how they could easily have turned this issue into a brand consolidation at nearly no cost, by following the advise of a stranger on the internet (from time to time they do have good ideas ): http://www.msfn.org/board/topic/128092-seagate-barracuda-720011-troubles/?p=897151 jaclaz

An extremely polite way to say that nlite gives powers to the user and with great power comes greater responsibility, which translated means "You removed too many things, your fault!" . An even more polite way to not say how the real reason is that they are a bunch of lazy, presumptuous, bastards, driven by their marketing department and while they perfectly know how to componentize Windows XP (which BTW they actually did in Windows Embedded) the thought of doing so for the "normal" version never crossed their minds , in other words, that is by design. jaclaz

Rather than guessing it, you might gather as much from what you have been explicitly told. A sysprep (online or offline) means "system preparation" (with the aim of making a system "deployable" or "universal"), quite obviously it needs a "system", until you have not the system (i.e. you have not installed it you miss a key element). It is IMHO important that you understand (as opposed to attempt guessing) what the differences are between the two approaches, each one has it's own advantages (and drawbacks) depending on the specific needs, and that you experiment with both to find yourself which night be better suited for your environment/needs. If you have to setup a number of identical machines, often a sysprep deploying is faster than unattended install, but if you make less than a high number of machines weekly or monthly, the time needed to setup a fully unattended install will simply not be worth the time, and a plain "attended" install (from an updated source) would be good as well. jaclaz

Meanwhile, in other news, Cortana is (will be made soon) available on Android : http://www.theverge.com/2015/7/17/8993015/microsoft-cortana-android-app-leak http://arstechnica.com/gadgets/2015/07/a-first-look-at-microsofts-cortana-running-on-android/ implying the need to signup on a Microsoft account (i.e. basically giving to MS the same kind of info that now you are giving exclusively to Google , a new form of democracy/equity) Seemingly it will be soon available for iOS too, though I doubt that any of the good iPhone guys will trade in Siri for Cortana jaclaz

Well, what jaclaz desperately tried to tell you (and definitely failed at it ) here: http://www.msfn.org/board/topic/174072-capturing-a-windows-xp-reference-image-after-sysprep/ is that installing an XP from .iso/install source or deploying an image of an already installed (and sysprepped) XP are two different ALTERNATIVES that cannot be "mixed together". You use EITHER an install (attended or unattended) OR a deployment solution, they are DIFFERENT procedures. jaclaz

Maybe. The point might be if that is a BIOS password or a hard disk password (ATA password). If it is a BIOS password, the contents of the disk are likely encrypted and/or any other hard disk replacing the one currently in the machine won't be accessible. It is possible (but not very likely) that a procedure to remove the password exists, but (it depends on specific make/model) as an example a number of laptops use a dedicated chip to it, and the chip needs to be replaced (by de-soldering it and replacing it weith a "blank" one). If it is an ATA password, depending on make/model of the hard disk and the security level of the password it may be possible to reset it (keeping the data in the hard disk) or remove it (losing all data in the hard disk). jaclaz

For NO apparent reason : https://veracrypt.codeplex.com/ jaclaz

Still OT , but not much: http://venturebeat.com/2015/05/29/in-a-mobile-first-world-74-of-consumers-still-buy-products-using-a-computer/ jaclaz

... meanwhile in Cupertino .... Negative votes on Apps: http://www.macstories.net/stories/on-negative-app-store-reviews-during-betas-of-ios-and-os-x/ jaclaz

Yep , but the real problem (besides geographical distance) is that we know very little about a single (actually two) very specific issues originating from a same very specific firmware implementation on a different (though similar) drive, the 7200.11, and we know even less on these "LP Green" things, specifically we have a single "vague" report of success coming from a post on the Seagate board, quoted here: http://www.msfn.org/board/topic/150475-st2000dl003-seagate-barracuda-lp-green-2000gb-suddenly-ceases/?p=990707 and (maybe) a single "even more vague" confirmation: http://www.msfn.org/board/topic/150475-st2000dl003-seagate-barracuda-lp-green-2000gb-suddenly-ceases/?p=1091946 Please do note how the ONLY (as said "vague" and not properly confirmed) source runs only a "i" command that clears (possibly without any real need ) the g-list and then runs just a "N" command (clearing the S.M.A.R.T.) and EXPLICITLY tells you to NOT run any "m" commands: and we have at least a confirmation that running the "m0,2,2,,,,,22": http://www.msfn.org/board/topic/161029-seagate-barracuda-lp-green-is-not-recognized-in-bios-suddenly/ actually further "bricks" the device into a "No HOST FIS-ReadyStatusFlags 0002A1E1" . jaclaz

Well, this time it seems like it is a serious issue, not the usual media hype/fluff: http://www.pcworld.com/article/2945472/cybercriminals-start-using-flash-zeroday-exploit-leaked-from-hacking-team.html https://krebsonsecurity.com/2015/07/third-hacking-team-flash-zero-day-found/ jaclaz

Then trust the video and don't do the shorting. If you are NOT locked out with a LED:00000xxx FAddr:0000yyyy error, you are fine , otherwise you might need to find way to exit that loop . The 7200.12 is NOT a "LP green" model like we are talking about in this thread, however, see: http://www.msfn.org/board/topic/157329-barracuda-lp-no-not-a-720011-nor-a-720012/ No, you don't. You read here that a user who used blindly the commands suggested as a remedy for a given illness on a completely different issue/problem had a 50% rate of success (one disk out of two) and since there was nothing to lose on the disk that he failed to revive, was suggested to try some other commands, in the remote hypothesis that they could work. DO NOT EVEN THINK of running any command unless you are pretty sure of the exact drive model involved, and the exact nature of the issue. DO NOT ASSUME that the procedure for another disk model can apply to your disk, a video may be a good visual reference for the generic process of accessing the disk, but nothing more. jaclaz

It seems like the "get a free license" and "accept ..." should be put in the past tense: http://www.msfn.org/board/topic/174093-windows-10-insider-preview-product-keys-have-been-disabled/ Who already was an insider and has an already working install can go along that plan, but no "new installs", seemingly. jaclaz

JFYI: http://www.theregister.co.uk/2015/06/05/kaspersky_says_airgap_industrial_systems_why_not_airgap_baby_monitors_as_well/ 'nuf said 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