I rent out my room to a lodger and would like to give him access to my wireless internet connection. I'm worried that he might download illegal material, and that I'll run into problems after he's gone. Is there any way to give him access while at same time preventing illegal activity?
I presume you're referring to file-sharing. After all, if you're concerned about your lodger engaging in other sorts of "illegal activity" then you shouldn't have him living in your house!
With regard to copyright infringement, your legal position should actually be quite strong: a recent court ruling found that the law doesn't hold broadband subscribers liable for uploads and downloads that they haven't explicitly authorized. This isn't a binding judgment, though, so for now it's understandable that you'd wish to err on the side of caution.
Unfortunately, there isn't much you can practically do to prevent your lodger from sharing copyright material, should he so wish. Normally, internet filtering would be a job for parental control software, but such tools run locally on the PC, and I doubt your lodger would take kindly to your installing a website blocker on his laptop.
Depending on what sort of router you have, it might have an option to block BitTorrent transfers. Such settings aren't foolproof: if someone is determined to share files, they can use encryption and tunneling to sneak their traffic through. But if your router has such an option then it would do no harm to enable it. Doing so would send a message that you don't endorse file-sharing, and if it prompted your lodger to use encryption then that would at least reduce the likelihood of him being caught.
If you really want to lock down your internet connection, you'll need more sophisticated hardware. If you have a spare PC, for example, you could install the free IPCop Linux firewall on it (www. ipcop.org) and use it in conjunction with the free L7 Filter that identifies and blocks peer-to-peer traffic (http:// l7- filter.sourceforge.n et). Clearly, though, this is a big, complex project.
Source of Information : PC Pro -April 2011
Running WEP and WPA2 in parallel is problematic, as most routers require you to choose one or the other
Next, configure the WEP router not to issue any IP addresses, but instead to forward DHCP requests to the master router. I'm not sure which of your routers is which, but the way you achieve this is the same in both: in the LAN settings page, under General Setup, select the button for "Disable Server", and in the box marked "DHC Server IP Address for Relay Agent", enter the address of the master router (normally 192.168.1.1). You might also need to enter this address in the Gateway IP Address box, and clear the entries for 1st IP Address and 2nd IP Address, so that the WEP router itself obtains an IP address from the master router.
Effectively, what you're doing here is turning your WEP router into an access point that simply acts as a bridge between your wireless devices and the master router. This will allow the master router to assign IP addresses to your WEP clients, after which it should be happy to handle internet traffic for them.
Source of Information : PC Pro -April 2011
Effectively, what you're doing here is turning your WEP router into an access point that simply acts as a bridge between your wireless devices and the master router. This will allow the master router to assign IP addresses to your WEP clients, after which it should be happy to handle internet traffic for them.
Source of Information : PC Pro -April 2011
THE UBUNTU FILE SYSTEM
Folder locations Once you start working in Ubuntu, you'll want to know where to save your files. Ubuntu gives you a personal home directory, with subdirectories already set up for Documents, Music, Pictures, Videos and Downloads. There's also a Public folder: files stored here will be available to anyone who logs on to your PC.
Drivesand devices. Ubuntu can read and write disks and partitions that use the familiar FAT32 and NTFS formats, but by default it uses a more advanced format called Ext4. This format is less likely to lose data in the event of a crash, and it can support large disks or files. The downside is that Windows can't read it – something to be aware of if you want to share files across a dual-boot PC. Another difference is the way the file system is organized. In Windows, each drive in your system has its directory hierarchy – so, for example, a folder on a USB flash drive might be addressed as "E: Files \Test file.doc". In Ubuntu there's a single root directory for the entire system, referred to simply as "I" (a "regular" slash, not a backslash as used by Windows), and all disks and devices appear within this hierarchy. You can see how this works by opening the Ubuntu File Manager and clicking on File System to view the root directory. You'll see a folder called /media, and if you've installed Ubuntu alongside a Windows installation, there will be a link within this folder to your Windows partition (your files are in /host if you've installed Ubuntu on the same partition as Windows, using the Wubi installer). Plug in a USB flash drive and that will appear here too. There are many other top-level directories besides /media, but unless you get into advanced system administration, only a few are worth knowing about. (Even so, most first-time users of Ubuntu probably won't be venturing anywhere near them.) The /etc directory contains hardware-specific settings, where you'll find configuration files for things such as graphics cards and printers. /usr is where most apps and libraries go when you install them, and /home contains the home folders for all the users on the system.
Virtual folders. As the contents of the /media directory demonstrate, a directory in Ubuntu may not be a "real" directory: it could be a link to a different device or to a different location on the same disk. This approach takes some getting used to, but it adds a level of flexibility. In schools and businesses that run Unix-type systems, for example, it's common for /home to be not a regular directory but a link to a different disk, or even a remote network location. This makes it easy to back up users' data or move it to a different PC, independently to the rest of the OS. (This type of virtual folder is called a "mount point".) If you want to reorganize your own directories, you'll find full instructions in the online Ubuntu documentation at http://help.ubuntu.com. Be warned, though, you'll need to use the Terminal, and there are some technical issues involved. One other thing to note is that in Ubuntu, filenames and paths are case sensitive – so a folder called "data" isn't the same as one called "Data". Remember that, or it will trip you up!
File permissions. A final important difference between the Windows and Ubuntu file systems relates to file permissions. In Windows, you can access almost any file or folder on your system — although there are a few circumstances when you might need to take ownership of a system file. Ubuntu is stricter. System and configuration files are owned by an administrator account called "root", and when you're logged in under your own name, you have only limited access to things outside of your home directory. That's normal, and it's for your own safety — it makes it almost impossible for you to accidentally mess up your system. These restrictions also apply to programs you run under that account, which makes Ubuntu resistant to Trojans and other sorts of malware. If you do need to edit system files, you can do so using a Terminal command called "sudo", which temporarily promotes you to a " superuser". You'll find everything you need to know about File Permissions and the sudo command in the online documentation.
Source of Information : PC Pro -April 2011
Drivesand devices. Ubuntu can read and write disks and partitions that use the familiar FAT32 and NTFS formats, but by default it uses a more advanced format called Ext4. This format is less likely to lose data in the event of a crash, and it can support large disks or files. The downside is that Windows can't read it – something to be aware of if you want to share files across a dual-boot PC. Another difference is the way the file system is organized. In Windows, each drive in your system has its directory hierarchy – so, for example, a folder on a USB flash drive might be addressed as "E: Files \Test file.doc". In Ubuntu there's a single root directory for the entire system, referred to simply as "I" (a "regular" slash, not a backslash as used by Windows), and all disks and devices appear within this hierarchy. You can see how this works by opening the Ubuntu File Manager and clicking on File System to view the root directory. You'll see a folder called /media, and if you've installed Ubuntu alongside a Windows installation, there will be a link within this folder to your Windows partition (your files are in /host if you've installed Ubuntu on the same partition as Windows, using the Wubi installer). Plug in a USB flash drive and that will appear here too. There are many other top-level directories besides /media, but unless you get into advanced system administration, only a few are worth knowing about. (Even so, most first-time users of Ubuntu probably won't be venturing anywhere near them.) The /etc directory contains hardware-specific settings, where you'll find configuration files for things such as graphics cards and printers. /usr is where most apps and libraries go when you install them, and /home contains the home folders for all the users on the system.
Virtual folders. As the contents of the /media directory demonstrate, a directory in Ubuntu may not be a "real" directory: it could be a link to a different device or to a different location on the same disk. This approach takes some getting used to, but it adds a level of flexibility. In schools and businesses that run Unix-type systems, for example, it's common for /home to be not a regular directory but a link to a different disk, or even a remote network location. This makes it easy to back up users' data or move it to a different PC, independently to the rest of the OS. (This type of virtual folder is called a "mount point".) If you want to reorganize your own directories, you'll find full instructions in the online Ubuntu documentation at http://help.ubuntu.com. Be warned, though, you'll need to use the Terminal, and there are some technical issues involved. One other thing to note is that in Ubuntu, filenames and paths are case sensitive – so a folder called "data" isn't the same as one called "Data". Remember that, or it will trip you up!
File permissions. A final important difference between the Windows and Ubuntu file systems relates to file permissions. In Windows, you can access almost any file or folder on your system — although there are a few circumstances when you might need to take ownership of a system file. Ubuntu is stricter. System and configuration files are owned by an administrator account called "root", and when you're logged in under your own name, you have only limited access to things outside of your home directory. That's normal, and it's for your own safety — it makes it almost impossible for you to accidentally mess up your system. These restrictions also apply to programs you run under that account, which makes Ubuntu resistant to Trojans and other sorts of malware. If you do need to edit system files, you can do so using a Terminal command called "sudo", which temporarily promotes you to a " superuser". You'll find everything you need to know about File Permissions and the sudo command in the online documentation.
Source of Information : PC Pro -April 2011
RUNNING WINDOWS APPS IN UBUNTU
No matter how many useful applications come bundled with Ubuntu, it's difficult to live without some Windows programs, particularly if you work in an industry where, say, Word, Excel or Photoshop compatibility is a must. Luckily, it's entirely possible to run many Windows applications within Ubuntu using an optional package, Wine.
Wine is frequently described as an emulator, but in fact it works as a " compatibility layer" offering Linux-based alternatives to the libraries that Windows applications call on during use, and a process — the winerserver — that translates the functions of the Windows kernel and UI into their Linux equivalents. Using these and some clever jiggery-pokery with file systems, Wine convinces Windows apps that they're running on a Microsoft OS and enables them to run happily on Ubuntu with a minimal performance hit. The good news is that it's usually easy to use. First, you need to install Wine: search for it in the Ubuntu Software Centre, or download the latest version from www.winehq.org.
Now, it's time to install your Windows app. Just download the file or insert the CD or DVD, and you can often doubeclick on the standard Windows installer (or let the CD autorun) and install an application just as you would in Windows. Wine handles the whole thing for you, practically transparently. Nor is there any hassle in running installed software: you can either run the application from a desktop shortcut or from Applications I Wine 1 Programs.
Sadly, Wine doesn't always flow smoothly, and not all applications work perfectly first time. Some just won't work whatever you do, while others rely on security systems that scupper Wine. Others will work, but with limited functionality, woeful stability or significant bugs. On the plus side, winehq.org maintains a database of Windows applications, with volunteers testing new software as it appears, and grading them from Platinum (runs flawlessly out of the box) to Garbage ( won't work at all). Office 2007 and Word 2007, for example, are rated as Silver and will work for most English-language users straight away. InDesign CS3 and CS4, however, are listed as Garbage, although they may install and run as part of an Adobe Creative Suite.
It's important to note that these findings are dependent on who and how many people have tested, and that your mileage will vary. For example, the Office 2010 32-bit installer is currently listed as Bronze, while Word 2010 is listed as Garbage. However, we've had people within the PC Pro office comfortably using Word 2010 within Ubuntu.
Meanwhile, you'll find some games listed as Platinum, then struggle for hours to get them working in Ubuntu. It's also entirely possible to find applications that will fail on your first attempt to install, but succeed on the second for no real reason. Overall, however, the WineHQ database is a fairly reliable guide, and worth consulting if you need to use a specific application.
TroubleshootingWine
What can you do if Wine doesn't work? Well, there are some useful tricks you might want to deploy. First, it's possible to configure Wine to behave like a specific version &Windows, by going to Applications I Wine I Configure Wine, clicking the Add Application button to add a Windows application to the list, and then setting the Windows Version using the dropdown menu at the bottom of the screen.
In some cases, you can also use the Graphics settings tab of the Wine Configuration menu to either start the application within a virtual desktop or switch off Direct3D hardware support. Of course, doing so might make some applications, notably games, virtually unusable. There are also Wine plugins, such as the incredibly useful Winetricks script, which install additional Windows libraries and ensure maximum compatibility.
Some of these are integrated into the default Ubuntu Wine installation or the latest version downloadable from WineHQ – but don't take anything for granted. You can see more detailed instructions at http://wiki. winehq.org/winetricics. If you're planning to run games then give the PlayOnLinux application a try. This acts as a front-end for Wine and incorporates a range of Wine scripts and additional Windows libraries, all in aid of getting as many games as possible to run. It also supports Valve's Steam client, allowing you to persuade a number of games that you may have already purchased on a Windows PC to run within Ubuntu using Wine. Making heavier use of graphics and audio hardware, games can occasionally be challenging to get working, but the WineHQ apps database offers excellent support.
Most of all, remember that the WineHQ database contains a mass of information, and that Google is your friend. With so many Ubuntu users trying to get Windows applications to work, it's likely that someone will have encountered the same difficulties as you and – hopefully found a way to solve them.
Wine is frequently described as an emulator, but in fact it works as a " compatibility layer" offering Linux-based alternatives to the libraries that Windows applications call on during use, and a process — the winerserver — that translates the functions of the Windows kernel and UI into their Linux equivalents. Using these and some clever jiggery-pokery with file systems, Wine convinces Windows apps that they're running on a Microsoft OS and enables them to run happily on Ubuntu with a minimal performance hit. The good news is that it's usually easy to use. First, you need to install Wine: search for it in the Ubuntu Software Centre, or download the latest version from www.winehq.org.
Now, it's time to install your Windows app. Just download the file or insert the CD or DVD, and you can often doubeclick on the standard Windows installer (or let the CD autorun) and install an application just as you would in Windows. Wine handles the whole thing for you, practically transparently. Nor is there any hassle in running installed software: you can either run the application from a desktop shortcut or from Applications I Wine 1 Programs.
Sadly, Wine doesn't always flow smoothly, and not all applications work perfectly first time. Some just won't work whatever you do, while others rely on security systems that scupper Wine. Others will work, but with limited functionality, woeful stability or significant bugs. On the plus side, winehq.org maintains a database of Windows applications, with volunteers testing new software as it appears, and grading them from Platinum (runs flawlessly out of the box) to Garbage ( won't work at all). Office 2007 and Word 2007, for example, are rated as Silver and will work for most English-language users straight away. InDesign CS3 and CS4, however, are listed as Garbage, although they may install and run as part of an Adobe Creative Suite.
It's important to note that these findings are dependent on who and how many people have tested, and that your mileage will vary. For example, the Office 2010 32-bit installer is currently listed as Bronze, while Word 2010 is listed as Garbage. However, we've had people within the PC Pro office comfortably using Word 2010 within Ubuntu.
Meanwhile, you'll find some games listed as Platinum, then struggle for hours to get them working in Ubuntu. It's also entirely possible to find applications that will fail on your first attempt to install, but succeed on the second for no real reason. Overall, however, the WineHQ database is a fairly reliable guide, and worth consulting if you need to use a specific application.
TroubleshootingWine
What can you do if Wine doesn't work? Well, there are some useful tricks you might want to deploy. First, it's possible to configure Wine to behave like a specific version &Windows, by going to Applications I Wine I Configure Wine, clicking the Add Application button to add a Windows application to the list, and then setting the Windows Version using the dropdown menu at the bottom of the screen.
In some cases, you can also use the Graphics settings tab of the Wine Configuration menu to either start the application within a virtual desktop or switch off Direct3D hardware support. Of course, doing so might make some applications, notably games, virtually unusable. There are also Wine plugins, such as the incredibly useful Winetricks script, which install additional Windows libraries and ensure maximum compatibility.
Some of these are integrated into the default Ubuntu Wine installation or the latest version downloadable from WineHQ – but don't take anything for granted. You can see more detailed instructions at http://wiki. winehq.org/winetricics. If you're planning to run games then give the PlayOnLinux application a try. This acts as a front-end for Wine and incorporates a range of Wine scripts and additional Windows libraries, all in aid of getting as many games as possible to run. It also supports Valve's Steam client, allowing you to persuade a number of games that you may have already purchased on a Windows PC to run within Ubuntu using Wine. Making heavier use of graphics and audio hardware, games can occasionally be challenging to get working, but the WineHQ apps database offers excellent support.
Most of all, remember that the WineHQ database contains a mass of information, and that Google is your friend. With so many Ubuntu users trying to get Windows applications to work, it's likely that someone will have encountered the same difficulties as you and – hopefully found a way to solve them.
Understanding Windows 7 Setup Process
In comparison to Windows XP, there are numerous differences in the deployment technologies that are now available with Windows 7 as new and improved tools have been developed based on technologies that were first introduced with Windows Vista. Before Windows Vista was released, Microsoft did not have robust tools to facilitate mass deployment. If you are unfamiliar with Windows Vista or your organization passed on it altogether, you might as well unlearn everything you know on Windows XP deployment and start from scratch.
Before we are able to prepare for volume deployments of Windows 7, it is important to understand the underlying processes of the installation so that we make the best use of the tools. There have been significant changes to the way the Windows operating system is now deployed. Let us first glance at the following list of things that have changed in deploying Windows since the Windows XP days:
» Booting up the Windows installation occurs through the Windows preinstallation environment (Windows PE), which replaces any DOS-based boot disk/media.
» Windows Setup is now a file-based image deployment.
» Installation source files may be 2 GB or higher.
» All Windows installations need to be activated.
» The Boot.ini is no longer used for boot configuration.
» Setup.exe is now the new command that launches the Windows installation process, replacing winnt32.exe.
» The Windows installation is independent from the Hardware Abstraction Layer (HAL.dll).
» Windows 7 is not language specific, whereas for Windows XP/2003 or earlier each language had its own build of the operating system. Languages are now separate packages.
» The Windows 7 DVD contains the source Windows Image (WIM) file containing all of the editions of this operating system’s version. The installer determines which product to install based on the license key.
The Windows 7 installation is now conducted through file-based images. What comes to mind when we talk about “imaging” is what in the industry is more commonly known as sector-based imaging. Numerous administrators have probably worked with third-party utilities for imaging such as Symantec Ghost (http://www.symantec.com/norton/ghost) or Acronis TrueImage (http://www.acronis.com/enterprise/) to take snapshots of a system volume in order to capture the desired system state and installation. The images these products capture are different from the WIM file format that is file-based. The main difference is that sector-based images copy indiscriminately sector-by-sector at a low level from a hard drive to build a snapshot of storage volume; file-based images such as WIM images are captured by taking snapshots at a higher level of files and folders. The bottom line is that even though sector-based images are very flexible because they can ignore the type of file system in use, they are somewhat unpractical to maintain and manage; in order to modify and edit a sector-based image, it would require deploying the image, making the changes, and recapturing it. In the case of WIM files, the action to modify and update the images can be performed by instantly “mounting” the captured image, applying the changes at the file system level, and then committing the changes immediately.
The image-based Windows setup process that was first introduced with Windows
Vista greatly facilitates the deployment of the operating system to disparate hardware architectures without requiring building separate installation packages/images. This same behavior can also be found in Windows 7, and it may come as good news to some administrators who did not have much exposure or were unable to deploy Vista. The way the new Windows 7 setup is designed streamlines many portions of previous operating system installations that would usually encounter obstacles when being deployed, especially from captured images.
There were many limitations when Windows XP images were deployed as these would not necessarily restore successfully on to any computer with a hardware architecture different than that of the system from which the image was captured. This created a lot of additional work for system administrators, including managing multiple images and developing custom scripts to force things to work properly. Important system components such as the HAL were tied to the specific installation device and would usually require additional steps/tools to allow a restored image to be reconfigured properly. Some of the known issues for Windows XP images include the following:
» The imaged computer is expected to boot from the same storage controller as the reference computer.
» The imaged systems need to use the same HAL as the reference computer.
» The sector-based imaging process is destructive; thus, it replaces all contents of the destination computer and could complicate some Windows deployment scenarios including in-place upgrades and other types of migrations.
» Maintaining the image to include updates and new applications was time consuming as directly modifying the image was not possible.
» The need for third-party imaging utilities that incurred additional licensing, training, and operational costs.
Windows 7 has several editions; however, all editions of Windows 7 use the same installation image (install.wim which may be found in the Sources folder of the installation media). What varies is that Microsoft packaged media that is specific to one edition, which means that if the setup is executed image from which the setup is based. Depending on the need of a particular system/user, the deployed OS can be any of the needed editions, and it will be installed without the need for additional source files. normally, it will allow the installation of just the edition that was purchased through the user interface; nevertheless, by using the unattended setup answer file (unattend.xml), it is possible to install any edition (provided that there is a license key available). By knowing this it is easier to understand that despite the many flavors of Windows 7, there is a universal
Source of Information : Syngress Microsoft Windows 7 Administrators Reference Jun 2010
Before we are able to prepare for volume deployments of Windows 7, it is important to understand the underlying processes of the installation so that we make the best use of the tools. There have been significant changes to the way the Windows operating system is now deployed. Let us first glance at the following list of things that have changed in deploying Windows since the Windows XP days:
» Booting up the Windows installation occurs through the Windows preinstallation environment (Windows PE), which replaces any DOS-based boot disk/media.
» Windows Setup is now a file-based image deployment.
» Installation source files may be 2 GB or higher.
» All Windows installations need to be activated.
» The Boot.ini is no longer used for boot configuration.
» Setup.exe is now the new command that launches the Windows installation process, replacing winnt32.exe.
» The Windows installation is independent from the Hardware Abstraction Layer (HAL.dll).
» Windows 7 is not language specific, whereas for Windows XP/2003 or earlier each language had its own build of the operating system. Languages are now separate packages.
» The Windows 7 DVD contains the source Windows Image (WIM) file containing all of the editions of this operating system’s version. The installer determines which product to install based on the license key.
The Windows 7 installation is now conducted through file-based images. What comes to mind when we talk about “imaging” is what in the industry is more commonly known as sector-based imaging. Numerous administrators have probably worked with third-party utilities for imaging such as Symantec Ghost (http://www.symantec.com/norton/ghost) or Acronis TrueImage (http://www.acronis.com/enterprise/) to take snapshots of a system volume in order to capture the desired system state and installation. The images these products capture are different from the WIM file format that is file-based. The main difference is that sector-based images copy indiscriminately sector-by-sector at a low level from a hard drive to build a snapshot of storage volume; file-based images such as WIM images are captured by taking snapshots at a higher level of files and folders. The bottom line is that even though sector-based images are very flexible because they can ignore the type of file system in use, they are somewhat unpractical to maintain and manage; in order to modify and edit a sector-based image, it would require deploying the image, making the changes, and recapturing it. In the case of WIM files, the action to modify and update the images can be performed by instantly “mounting” the captured image, applying the changes at the file system level, and then committing the changes immediately.
The image-based Windows setup process that was first introduced with Windows
Vista greatly facilitates the deployment of the operating system to disparate hardware architectures without requiring building separate installation packages/images. This same behavior can also be found in Windows 7, and it may come as good news to some administrators who did not have much exposure or were unable to deploy Vista. The way the new Windows 7 setup is designed streamlines many portions of previous operating system installations that would usually encounter obstacles when being deployed, especially from captured images.
There were many limitations when Windows XP images were deployed as these would not necessarily restore successfully on to any computer with a hardware architecture different than that of the system from which the image was captured. This created a lot of additional work for system administrators, including managing multiple images and developing custom scripts to force things to work properly. Important system components such as the HAL were tied to the specific installation device and would usually require additional steps/tools to allow a restored image to be reconfigured properly. Some of the known issues for Windows XP images include the following:
» The imaged computer is expected to boot from the same storage controller as the reference computer.
» The imaged systems need to use the same HAL as the reference computer.
» The sector-based imaging process is destructive; thus, it replaces all contents of the destination computer and could complicate some Windows deployment scenarios including in-place upgrades and other types of migrations.
» Maintaining the image to include updates and new applications was time consuming as directly modifying the image was not possible.
» The need for third-party imaging utilities that incurred additional licensing, training, and operational costs.
Windows 7 has several editions; however, all editions of Windows 7 use the same installation image (install.wim which may be found in the Sources folder of the installation media). What varies is that Microsoft packaged media that is specific to one edition, which means that if the setup is executed image from which the setup is based. Depending on the need of a particular system/user, the deployed OS can be any of the needed editions, and it will be installed without the need for additional source files. normally, it will allow the installation of just the edition that was purchased through the user interface; nevertheless, by using the unattended setup answer file (unattend.xml), it is possible to install any edition (provided that there is a license key available). By knowing this it is easier to understand that despite the many flavors of Windows 7, there is a universal
Source of Information : Syngress Microsoft Windows 7 Administrators Reference Jun 2010
Deploying Windows 7 in an Enterprise Environment - Deployment Scenarios
The deployment scenarios are the following: upgrade (in-place), new installation, refresh, and replace.
Upgrade Scenario
This scenario allows an installation of Windows Vista Service Pack 1 (SP1) or later to be upgraded to Windows 7 while preserving the user state and all transferrable settings and files, as well as maintaining the installation of existing applications. As discussed in the previous chapter, there is no direct upgrade path for Windows XP, and therefore, the refresh method must be used (which keeps files and settings but not installed applications). This deployment method is also assessed by the Windows Compatibility Wizard, which helps determine if any components need to be individually addressed before performing the upgrade.
Performing an upgrade may be one of the easiest and least complex methods for deploying Windows 7; however, there is a certain risk attached to this operation as all settings are imported “as-is” from the earlier version and the administrator does not have much control on what gets transferred. Unless the state and condition of the system are known, it may be preferable to opt for a scenario that allows for selectively preserving the settings.
New Installation
The new installation involves deploying a clean copy of Windows 7 on the target computer through a straightforward setup process. It is assumed that the hard drive and system volume have been properly partitioned and formatted. This type of installation will deliver the most consistent result because all settings are either the setup defaults or set by the administrator.
Refresh Scenario
Similar to the new installation, the refresh scenario contemplates performing a clean setup with the difference being that the target computer already contains a Windows operating system for which files and settings will be preserved (note that as a difference with the upgrade method, the installed applications are not taken into consideration). This scenario is especially useful in the event that preserving the user state is a priority as it still leverages the benefits of consistency that come through a new installation. This scenario can be automated with the latest version of the User State Migration Tool (USMT 4.0), which will collect the pertinent data for each user state found in the system and consequently restore it after the clean installation is performed.
Replace Scenario
This is very similar to the refresh scenario except that the target system is a new computer, which does not contain any files or settings. The scenario consists of conducting a new installation on the target computer, and then using the USMT 4.0 to transfer files and settings from the old computer. This scenario can be run side-by-side with an older system running Windows XP or Windows Vista.
Source of Information : Syngress Microsoft Windows 7 Administrators Reference Jun 2010
Upgrade Scenario
This scenario allows an installation of Windows Vista Service Pack 1 (SP1) or later to be upgraded to Windows 7 while preserving the user state and all transferrable settings and files, as well as maintaining the installation of existing applications. As discussed in the previous chapter, there is no direct upgrade path for Windows XP, and therefore, the refresh method must be used (which keeps files and settings but not installed applications). This deployment method is also assessed by the Windows Compatibility Wizard, which helps determine if any components need to be individually addressed before performing the upgrade.
Performing an upgrade may be one of the easiest and least complex methods for deploying Windows 7; however, there is a certain risk attached to this operation as all settings are imported “as-is” from the earlier version and the administrator does not have much control on what gets transferred. Unless the state and condition of the system are known, it may be preferable to opt for a scenario that allows for selectively preserving the settings.
New Installation
The new installation involves deploying a clean copy of Windows 7 on the target computer through a straightforward setup process. It is assumed that the hard drive and system volume have been properly partitioned and formatted. This type of installation will deliver the most consistent result because all settings are either the setup defaults or set by the administrator.
Refresh Scenario
Similar to the new installation, the refresh scenario contemplates performing a clean setup with the difference being that the target computer already contains a Windows operating system for which files and settings will be preserved (note that as a difference with the upgrade method, the installed applications are not taken into consideration). This scenario is especially useful in the event that preserving the user state is a priority as it still leverages the benefits of consistency that come through a new installation. This scenario can be automated with the latest version of the User State Migration Tool (USMT 4.0), which will collect the pertinent data for each user state found in the system and consequently restore it after the clean installation is performed.
Replace Scenario
This is very similar to the refresh scenario except that the target system is a new computer, which does not contain any files or settings. The scenario consists of conducting a new installation on the target computer, and then using the USMT 4.0 to transfer files and settings from the old computer. This scenario can be run side-by-side with an older system running Windows XP or Windows Vista.
Source of Information : Syngress Microsoft Windows 7 Administrators Reference Jun 2010
Deploying Windows 7 in an Enterprise Environment overview
In a nutshell, the deployment process intends to get Windows 7 on the specified target computers. Whether it is being installed on one or many systems, the general approach would be as follows:
» Prepare to build master installation – This step encompasses setting up a technician computer with the necessary tools, Windows 7 source files, applications, device drivers, and additional software packages. In this step, you would also prepare the setup automation by creating answer files and configuring a source distribution share.
» Build, test, and capture image of master installation – You will designate a reference or master computer in which you will use the answer file that was previously generated to run and test the Windows 7 installation from the distribution share and ensure that the setup automation works properly. After setup is complete, you can perform the necessary customizations to meet the needs of your business. Once you are satisfied with the master installation, you can then prepare it for duplication and thereafter capture your progress.
» Prepare deployment media and network distribution – In this step, you will make the captured image available on a network share that may be accessed by the destination computers to which the image will be deployed. Alternatively, the images may be stored on other media including a DVD, an external mass-storage device, or Windows Deployment Services (WDS).
» Run setup/transfer images on to destination computers – By accessing either the network share or the prepared media, you ultimately will deploy the prepared source media to get Windows 7 on the target computer.
Source of Information : Syngress Microsoft Windows 7 Administrators Reference Jun 2010
» Prepare to build master installation – This step encompasses setting up a technician computer with the necessary tools, Windows 7 source files, applications, device drivers, and additional software packages. In this step, you would also prepare the setup automation by creating answer files and configuring a source distribution share.
» Build, test, and capture image of master installation – You will designate a reference or master computer in which you will use the answer file that was previously generated to run and test the Windows 7 installation from the distribution share and ensure that the setup automation works properly. After setup is complete, you can perform the necessary customizations to meet the needs of your business. Once you are satisfied with the master installation, you can then prepare it for duplication and thereafter capture your progress.
» Prepare deployment media and network distribution – In this step, you will make the captured image available on a network share that may be accessed by the destination computers to which the image will be deployed. Alternatively, the images may be stored on other media including a DVD, an external mass-storage device, or Windows Deployment Services (WDS).
» Run setup/transfer images on to destination computers – By accessing either the network share or the prepared media, you ultimately will deploy the prepared source media to get Windows 7 on the target computer.
Source of Information : Syngress Microsoft Windows 7 Administrators Reference Jun 2010
Subscribe to:
Posts (Atom)
Cloud storage is for blocks too, not just files
One of the misconceptions about cloud storage is that it is only useful for storing files. This assumption comes from the popularity of file...
-
Smss is like any other user-mode process except for two differences: First, Windows considers Smss a trusted part of the operating system. S...
-
When Winload calls Ntoskrnl, it passes a data structure called the loader parameter block that contains the system and boot partition paths,...
-
Many of the virus, adware, security, and crash problems with Windows occu when someone installs a driver of dubious origin. The driver suppo...