| Home | Register | Members | Search | Windows Vista Tips | File Database | Links |
![]() |
| Thread Tools | Display Modes |
|
|
|
| |
|
kj [SBS MVP]
Guest
Posts: n/a
|
Kris wrote:
> Hi, > > I would like to migrate our existing SBS2003 server to a fresh SBS2003 > install, I would also like to virtualise the server. > > I do not want to perform the migration in a live environment and have > decided the best/safest way to practice/carry out the migration is in > a virtual test environment. I am looking to perform the migration > using the documentation pack available from sbsmigration.com > > I have managed to clone the existing server into a virtual machine > which is now isolated in a test environment. I would like to migrate > Active Directory and Exchange from this server to a fresh SBS 2003 > install. > > I was so excited when the virtual machine booted, then I logged in to > be prompted with the 'This product needs to be acivated' dialogue box! > > I phoned Microsoft and entered the installation ID which was not > successful, I also spoke to a number of Microsoft representitives > after being cut-off a number of times and given various numbers some > of which did not work. Eventually I got through to someone who > informed me the product cannot be activated as it is not licensed for > use in a virtual environment, although technical support may be able > to help for the small sum off £199 ![]() > > Can anyone advise me if it is possible to get my cloned server > working in a vitual environment? > > Many thanks in advance, > > Kris. Well, sort of. Technically it's not supported in a virtual enviroment, but other than a few issues, it works in one. FAX is one of those that doesn't without extrodinary measures. Anyway, you can have only one copy of SBS2003 activated at a time. You could install the eval version or do a fresh install from your media and run in grace mode until activation is required. But to move an activated copy to virtual requires that you reactivate the close and cease using the original. If you are using sbsmigration you should be getting support included with your purchase. Also use microsoft.public.windows.server.sbs for standard product issues. -- /kj |
|
|
|
|
|||
|
|||
|
Kris
Guest
Posts: n/a
|
Many thanks for your reply KJ.
The clone was taken during the Christmas period, is it possible the clones grace period has expired during the Christmas break or is there no grace period with a clone? I will try another physical to virtual conversion over the weekend to confirm. I understand that I need a volume license as the final install will be on a new server (no oem license) and the current sbs install is a Dell OEM install. I am also planning to utilise the high availability functionality available with VMware ESXI, will this be an issue with SBS and the activation issues you mentioned? Thanks, Kris "kj [SBS MVP]" wrote: > Kris wrote: > > Hi, > > > > I would like to migrate our existing SBS2003 server to a fresh SBS2003 > > install, I would also like to virtualise the server. > > > > I do not want to perform the migration in a live environment and have > > decided the best/safest way to practice/carry out the migration is in > > a virtual test environment. I am looking to perform the migration > > using the documentation pack available from sbsmigration.com > > > > I have managed to clone the existing server into a virtual machine > > which is now isolated in a test environment. I would like to migrate > > Active Directory and Exchange from this server to a fresh SBS 2003 > > install. > > > > I was so excited when the virtual machine booted, then I logged in to > > be prompted with the 'This product needs to be acivated' dialogue box! > > > > I phoned Microsoft and entered the installation ID which was not > > successful, I also spoke to a number of Microsoft representitives > > after being cut-off a number of times and given various numbers some > > of which did not work. Eventually I got through to someone who > > informed me the product cannot be activated as it is not licensed for > > use in a virtual environment, although technical support may be able > > to help for the small sum off £199 ![]() > > > > Can anyone advise me if it is possible to get my cloned server > > working in a vitual environment? > > > > Many thanks in advance, > > > > Kris. > > Well, sort of. Technically it's not supported in a virtual enviroment, but > other than a few issues, it works in one. FAX is one of those that doesn't > without extrodinary measures. > > Anyway, you can have only one copy of SBS2003 activated at a time. You could > install the eval version or do a fresh install from your media and run in > grace mode until activation is required. But to move an activated copy to > virtual requires that you reactivate the close and cease using the original. > > If you are using sbsmigration you should be getting support included with > your purchase. Also use microsoft.public.windows.server.sbs for standard > product issues. > > -- > /kj > > > . > |
|
|
|
|
|||
|
|||
|
kj [SBS MVP]
Guest
Posts: n/a
|
Kris wrote:
> Many thanks for your reply KJ. > > The clone was taken during the Christmas period, is it possible the > clones grace period has expired during the Christmas break or is > there no grace period with a clone? > I will try another physical to virtual conversion over the weekend to > confirm. Reactivation is triggered from the new hardware. > > I understand that I need a volume license as the final install will > be on a new server (no oem license) and the current sbs install is a > Dell OEM install. I am also planning to utilise the high > availability functionality available with VMware ESXI, will this be > an issue with SBS and the activation issues you mentioned? > Ah, OEM. Licensing is not your only concern. OEM built, cloned, and virtualized is still going to be an OEM install and retail or volume license keys are probably going to be another issue for you. You might consider doing a swing migration, perhaps a double swing, ending in a virtualized instance. www.sbsmigration.com Since you'll be having two seperate licenses, you could make this very invisible to the users. > > Thanks, > > Kris > > > "kj [SBS MVP]" wrote: > >> Kris wrote: >>> Hi, >>> >>> I would like to migrate our existing SBS2003 server to a fresh >>> SBS2003 install, I would also like to virtualise the server. >>> >>> I do not want to perform the migration in a live environment and >>> have decided the best/safest way to practice/carry out the >>> migration is in a virtual test environment. I am looking to >>> perform the migration using the documentation pack available from >>> sbsmigration.com >>> >>> I have managed to clone the existing server into a virtual machine >>> which is now isolated in a test environment. I would like to >>> migrate Active Directory and Exchange from this server to a fresh >>> SBS 2003 install. >>> >>> I was so excited when the virtual machine booted, then I logged in >>> to be prompted with the 'This product needs to be acivated' >>> dialogue box! >>> >>> I phoned Microsoft and entered the installation ID which was not >>> successful, I also spoke to a number of Microsoft representitives >>> after being cut-off a number of times and given various numbers some >>> of which did not work. Eventually I got through to someone who >>> informed me the product cannot be activated as it is not licensed >>> for use in a virtual environment, although technical support may be >>> able to help for the small sum off £199 ![]() >>> >>> Can anyone advise me if it is possible to get my cloned server >>> working in a vitual environment? >>> >>> Many thanks in advance, >>> >>> Kris. >> >> Well, sort of. Technically it's not supported in a virtual >> enviroment, but other than a few issues, it works in one. FAX is one >> of those that doesn't without extrodinary measures. >> >> Anyway, you can have only one copy of SBS2003 activated at a time. >> You could install the eval version or do a fresh install from your >> media and run in grace mode until activation is required. But to >> move an activated copy to virtual requires that you reactivate the >> close and cease using the original. >> >> If you are using sbsmigration you should be getting support included >> with your purchase. Also use microsoft.public.windows.server.sbs for >> standard product issues. >> >> -- >> /kj >> >> >> . -- /kj |
|
|
|
|
|||
|
|||
|
Kris
Guest
Posts: n/a
|
Hi KJ,
Reactivation triggered by new hardware pretty much scraps my plans if it cannot be reactivated, it would not have been an issue if there was a grace period. The whole plan relied upon having a clone of the existing server in a test environment, this would allow me to test the migration in advance in a non production environment. The hardware I have is as follows: Dell Poweredge 2600 running SBS 2003 (production server) Dell Poweredge 2900(1) (test environment) Dell Poweredge 2900(2) (test environment) SAN for storing virtual machine images (either off the shelf or Openfiler) The plan for the migration is (or was) as follows: Step 1: Convert Production SBS 2003 Poweredge 2600 to a virtual machine. Step 2: Copy Virtual machine created above to SAN in an isolated environment Step 3: Run cloned SBS 2003 on Poweredge 2900(1) running VMware ESXI Step 4: Clean virtual install of SBS 2003 on Poweredge 2900(2) running ESXI Step 5: Swing migration of Active Directory and Exchange from cloned SBS 2003 install to clean SBS 2003 install. Step 6: Poweredge 2900(1) that was running cloned SBS will now provide high availability incase Poweredge 2900(2) fails (the image that was running on server 2 will be loaded on server 1) Step 7: Once I am confident everything works the old production Poweredge 2600 will be utilised for backing up images etc (not running SBS) This plan/final topology provided the following advantages: 1) Migration can be practiced in advance 2) Migration is performed in an isolated virtual environment therefore no risk to the production server. Once migration is complete the old server can be removed from the network and the new servers introduced therefore virtually zero downtime! 3) Currently we have no budget and in theory the plan can be practiced/proven without any expenditure ready for when funding is available. This relied upon the clone working! 4) Provides better disaster recovery than we currently have 5) Removes software corruption issues present on the production server 6) More ram/CPU can be assigned to SBS than is currently available. The OS partition on the production server is 12gig which causes issues, this can be resized as part of the physical to virtual machine conversion. Unfortunately the licensing seems to be introducing so many barriers. I am now unsure about what licensing I need for the final topology (image running on server 2 but server 1 incase of failure) as well as the problem of what happens when the image loads up on server 1, will I have the same issue as with my clone? Is there any work around for the issue with the clone as this is a huge problem? Regards, Kris "kj [SBS MVP]" wrote: > Kris wrote: > > Many thanks for your reply KJ. > > > > The clone was taken during the Christmas period, is it possible the > > clones grace period has expired during the Christmas break or is > > there no grace period with a clone? > > I will try another physical to virtual conversion over the weekend to > > confirm. > > Reactivation is triggered from the new hardware. > > > > > I understand that I need a volume license as the final install will > > be on a new server (no oem license) and the current sbs install is a > > Dell OEM install. I am also planning to utilise the high > > availability functionality available with VMware ESXI, will this be > > an issue with SBS and the activation issues you mentioned? > > > > Ah, OEM. Licensing is not your only concern. OEM built, cloned, and > virtualized is still going to be an OEM install and retail or volume license > keys are probably going to be another issue for you. > > You might consider doing a swing migration, perhaps a double swing, ending > in a virtualized instance. www.sbsmigration.com > > Since you'll be having two seperate licenses, you could make this very > invisible to the users. > > > > > Thanks, > > > > Kris > > > > > > "kj [SBS MVP]" wrote: > > > >> Kris wrote: > >>> Hi, > >>> > >>> I would like to migrate our existing SBS2003 server to a fresh > >>> SBS2003 install, I would also like to virtualise the server. > >>> > >>> I do not want to perform the migration in a live environment and > >>> have decided the best/safest way to practice/carry out the > >>> migration is in a virtual test environment. I am looking to > >>> perform the migration using the documentation pack available from > >>> sbsmigration.com > >>> > >>> I have managed to clone the existing server into a virtual machine > >>> which is now isolated in a test environment. I would like to > >>> migrate Active Directory and Exchange from this server to a fresh > >>> SBS 2003 install. > >>> > >>> I was so excited when the virtual machine booted, then I logged in > >>> to be prompted with the 'This product needs to be acivated' > >>> dialogue box! > >>> > >>> I phoned Microsoft and entered the installation ID which was not > >>> successful, I also spoke to a number of Microsoft representitives > >>> after being cut-off a number of times and given various numbers some > >>> of which did not work. Eventually I got through to someone who > >>> informed me the product cannot be activated as it is not licensed > >>> for use in a virtual environment, although technical support may be > >>> able to help for the small sum off £199 ![]() > >>> > >>> Can anyone advise me if it is possible to get my cloned server > >>> working in a vitual environment? > >>> > >>> Many thanks in advance, > >>> > >>> Kris. > >> > >> Well, sort of. Technically it's not supported in a virtual > >> enviroment, but other than a few issues, it works in one. FAX is one > >> of those that doesn't without extrodinary measures. > >> > >> Anyway, you can have only one copy of SBS2003 activated at a time. > >> You could install the eval version or do a fresh install from your > >> media and run in grace mode until activation is required. But to > >> move an activated copy to virtual requires that you reactivate the > >> close and cease using the original. > >> > >> If you are using sbsmigration you should be getting support included > >> with your purchase. Also use microsoft.public.windows.server.sbs for > >> standard product issues. > >> > >> -- > >> /kj > >> > >> > >> . > > -- > /kj > > > . > |
|
|
|
|
|||
|
|||
|
kj [SBS MVP]
Guest
Posts: n/a
|
It's that dang OEM software thing again. If the OEM didn't tie it to
hardware you might technically get away with it, but if the same hardware wasn't running the virtualization server, then you wouldn't be legal. An approach might be to convert the OEM instance before you clone and move it. Reported methods have been to boot the VL media and do a repair on the OEM install but I can't personally confirm this and of course would highly recommend a full and complete verified backup before you start experimenting with your production instance. Kris wrote: > Hi KJ, > > Reactivation triggered by new hardware pretty much scraps my plans if > it cannot be reactivated, it would not have been an issue if there > was a grace period. The whole plan relied upon having a clone of the > existing server in a test environment, this would allow me to test > the migration in advance in a non production environment. > > The hardware I have is as follows: > > Dell Poweredge 2600 running SBS 2003 (production server) > Dell Poweredge 2900(1) (test environment) > Dell Poweredge 2900(2) (test environment) > SAN for storing virtual machine images (either off the shelf or > Openfiler) > > The plan for the migration is (or was) as follows: > > Step 1: > > Convert Production SBS 2003 Poweredge 2600 to a virtual machine. > > Step 2: > > Copy Virtual machine created above to SAN in an isolated environment > > Step 3: > > Run cloned SBS 2003 on Poweredge 2900(1) running VMware ESXI > > Step 4: > > Clean virtual install of SBS 2003 on Poweredge 2900(2) running ESXI > > Step 5: > > Swing migration of Active Directory and Exchange from cloned SBS 2003 > install to clean SBS 2003 install. > > Step 6: > > Poweredge 2900(1) that was running cloned SBS will now provide high > availability incase Poweredge 2900(2) fails (the image that was > running on server 2 will be loaded on server 1) > > Step 7: > > Once I am confident everything works the old production Poweredge > 2600 will be utilised for backing up images etc (not running SBS) > > This plan/final topology provided the following advantages: > > 1) Migration can be practiced in advance > 2) Migration is performed in an isolated virtual environment > therefore no risk to > the production server. Once migration is complete the old server > can be removed from the network and the new servers introduced > therefore > virtually > zero downtime! > 3) Currently we have no budget and in theory the plan can be > practiced/proven without any expenditure ready for when funding > is available. This > relied upon > the clone working! > 4) Provides better disaster recovery than we currently have > 5) Removes software corruption issues present on the production > server 6) More ram/CPU can be assigned to SBS than is currently > available. The OS partition on the production server is 12gig > which causes issues, this > can be > resized as part of the physical to virtual machine conversion. > > Unfortunately the licensing seems to be introducing so many barriers. > I am now unsure about what licensing I need for the final topology > (image running on server 2 but server 1 incase of failure) as well as > the problem of what happens when the image loads up on server 1, will > I have the same issue as with my clone? > > Is there any work around for the issue with the clone as this is a > huge problem? > > > Regards, > > Kris > > > "kj [SBS MVP]" wrote: > >> Kris wrote: >>> Many thanks for your reply KJ. >>> >>> The clone was taken during the Christmas period, is it possible the >>> clones grace period has expired during the Christmas break or is >>> there no grace period with a clone? >>> I will try another physical to virtual conversion over the weekend >>> to confirm. >> >> Reactivation is triggered from the new hardware. >> >>> >>> I understand that I need a volume license as the final install will >>> be on a new server (no oem license) and the current sbs install is a >>> Dell OEM install. I am also planning to utilise the high >>> availability functionality available with VMware ESXI, will this be >>> an issue with SBS and the activation issues you mentioned? >>> >> >> Ah, OEM. Licensing is not your only concern. OEM built, cloned, and >> virtualized is still going to be an OEM install and retail or volume >> license keys are probably going to be another issue for you. >> >> You might consider doing a swing migration, perhaps a double swing, >> ending in a virtualized instance. www.sbsmigration.com >> >> Since you'll be having two seperate licenses, you could make this >> very invisible to the users. >> >>> >>> Thanks, >>> >>> Kris >>> >>> >>> "kj [SBS MVP]" wrote: >>> >>>> Kris wrote: >>>>> Hi, >>>>> >>>>> I would like to migrate our existing SBS2003 server to a fresh >>>>> SBS2003 install, I would also like to virtualise the server. >>>>> >>>>> I do not want to perform the migration in a live environment and >>>>> have decided the best/safest way to practice/carry out the >>>>> migration is in a virtual test environment. I am looking to >>>>> perform the migration using the documentation pack available from >>>>> sbsmigration.com >>>>> >>>>> I have managed to clone the existing server into a virtual machine >>>>> which is now isolated in a test environment. I would like to >>>>> migrate Active Directory and Exchange from this server to a fresh >>>>> SBS 2003 install. >>>>> >>>>> I was so excited when the virtual machine booted, then I logged in >>>>> to be prompted with the 'This product needs to be acivated' >>>>> dialogue box! >>>>> >>>>> I phoned Microsoft and entered the installation ID which was not >>>>> successful, I also spoke to a number of Microsoft representitives >>>>> after being cut-off a number of times and given various numbers >>>>> some of which did not work. Eventually I got through to someone >>>>> who informed me the product cannot be activated as it is not >>>>> licensed for use in a virtual environment, although technical >>>>> support may be able to help for the small sum off £199 ![]() >>>>> >>>>> Can anyone advise me if it is possible to get my cloned server >>>>> working in a vitual environment? >>>>> >>>>> Many thanks in advance, >>>>> >>>>> Kris. >>>> >>>> Well, sort of. Technically it's not supported in a virtual >>>> enviroment, but other than a few issues, it works in one. FAX is >>>> one of those that doesn't without extrodinary measures. >>>> >>>> Anyway, you can have only one copy of SBS2003 activated at a time. >>>> You could install the eval version or do a fresh install from your >>>> media and run in grace mode until activation is required. But to >>>> move an activated copy to virtual requires that you reactivate the >>>> close and cease using the original. >>>> >>>> If you are using sbsmigration you should be getting support >>>> included with your purchase. Also use >>>> microsoft.public.windows.server.sbs for standard product issues. >>>> >>>> -- >>>> /kj >>>> >>>> >>>> . >> >> -- >> /kj >> >> >> . -- /kj |
|
|
|
|
|||
|
|||
|
Kris
Guest
Posts: n/a
|
KJ, I managed to find a work around on the VMware forums, once again full steam ahead ![]() Thanks for your help. Kris "kj [SBS MVP]" wrote: > It's that dang OEM software thing again. If the OEM didn't tie it to > hardware you might technically get away with it, but if the same hardware > wasn't running the virtualization server, then you wouldn't be legal. > > An approach might be to convert the OEM instance before you clone and move > it. Reported methods have been to boot the VL media and do a repair on the > OEM install but I can't personally confirm this and of course would highly > recommend a full and complete verified backup before you start experimenting > with your production instance. > > > Kris wrote: > > Hi KJ, > > > > Reactivation triggered by new hardware pretty much scraps my plans if > > it cannot be reactivated, it would not have been an issue if there > > was a grace period. The whole plan relied upon having a clone of the > > existing server in a test environment, this would allow me to test > > the migration in advance in a non production environment. > > > > The hardware I have is as follows: > > > > Dell Poweredge 2600 running SBS 2003 (production server) > > Dell Poweredge 2900(1) (test environment) > > Dell Poweredge 2900(2) (test environment) > > SAN for storing virtual machine images (either off the shelf or > > Openfiler) > > > > The plan for the migration is (or was) as follows: > > > > Step 1: > > > > Convert Production SBS 2003 Poweredge 2600 to a virtual machine. > > > > Step 2: > > > > Copy Virtual machine created above to SAN in an isolated environment > > > > Step 3: > > > > Run cloned SBS 2003 on Poweredge 2900(1) running VMware ESXI > > > > Step 4: > > > > Clean virtual install of SBS 2003 on Poweredge 2900(2) running ESXI > > > > Step 5: > > > > Swing migration of Active Directory and Exchange from cloned SBS 2003 > > install to clean SBS 2003 install. > > > > Step 6: > > > > Poweredge 2900(1) that was running cloned SBS will now provide high > > availability incase Poweredge 2900(2) fails (the image that was > > running on server 2 will be loaded on server 1) > > > > Step 7: > > > > Once I am confident everything works the old production Poweredge > > 2600 will be utilised for backing up images etc (not running SBS) > > > > This plan/final topology provided the following advantages: > > > > 1) Migration can be practiced in advance > > 2) Migration is performed in an isolated virtual environment > > therefore no risk to > > the production server. Once migration is complete the old server > > can be removed from the network and the new servers introduced > > therefore > > virtually > > zero downtime! > > 3) Currently we have no budget and in theory the plan can be > > practiced/proven without any expenditure ready for when funding > > is available. This > > relied upon > > the clone working! > > 4) Provides better disaster recovery than we currently have > > 5) Removes software corruption issues present on the production > > server 6) More ram/CPU can be assigned to SBS than is currently > > available. The OS partition on the production server is 12gig > > which causes issues, this > > can be > > resized as part of the physical to virtual machine conversion. > > > > Unfortunately the licensing seems to be introducing so many barriers. > > I am now unsure about what licensing I need for the final topology > > (image running on server 2 but server 1 incase of failure) as well as > > the problem of what happens when the image loads up on server 1, will > > I have the same issue as with my clone? > > > > Is there any work around for the issue with the clone as this is a > > huge problem? > > > > > > Regards, > > > > Kris > > > > > > "kj [SBS MVP]" wrote: > > > >> Kris wrote: > >>> Many thanks for your reply KJ. > >>> > >>> The clone was taken during the Christmas period, is it possible the > >>> clones grace period has expired during the Christmas break or is > >>> there no grace period with a clone? > >>> I will try another physical to virtual conversion over the weekend > >>> to confirm. > >> > >> Reactivation is triggered from the new hardware. > >> > >>> > >>> I understand that I need a volume license as the final install will > >>> be on a new server (no oem license) and the current sbs install is a > >>> Dell OEM install. I am also planning to utilise the high > >>> availability functionality available with VMware ESXI, will this be > >>> an issue with SBS and the activation issues you mentioned? > >>> > >> > >> Ah, OEM. Licensing is not your only concern. OEM built, cloned, and > >> virtualized is still going to be an OEM install and retail or volume > >> license keys are probably going to be another issue for you. > >> > >> You might consider doing a swing migration, perhaps a double swing, > >> ending in a virtualized instance. www.sbsmigration.com > >> > >> Since you'll be having two seperate licenses, you could make this > >> very invisible to the users. > >> > >>> > >>> Thanks, > >>> > >>> Kris > >>> > >>> > >>> "kj [SBS MVP]" wrote: > >>> > >>>> Kris wrote: > >>>>> Hi, > >>>>> > >>>>> I would like to migrate our existing SBS2003 server to a fresh > >>>>> SBS2003 install, I would also like to virtualise the server. > >>>>> > >>>>> I do not want to perform the migration in a live environment and > >>>>> have decided the best/safest way to practice/carry out the > >>>>> migration is in a virtual test environment. I am looking to > >>>>> perform the migration using the documentation pack available from > >>>>> sbsmigration.com > >>>>> > >>>>> I have managed to clone the existing server into a virtual machine > >>>>> which is now isolated in a test environment. I would like to > >>>>> migrate Active Directory and Exchange from this server to a fresh > >>>>> SBS 2003 install. > >>>>> > >>>>> I was so excited when the virtual machine booted, then I logged in > >>>>> to be prompted with the 'This product needs to be acivated' > >>>>> dialogue box! > >>>>> > >>>>> I phoned Microsoft and entered the installation ID which was not > >>>>> successful, I also spoke to a number of Microsoft representitives > >>>>> after being cut-off a number of times and given various numbers > >>>>> some of which did not work. Eventually I got through to someone > >>>>> who informed me the product cannot be activated as it is not > >>>>> licensed for use in a virtual environment, although technical > >>>>> support may be able to help for the small sum off £199 ![]() > >>>>> > >>>>> Can anyone advise me if it is possible to get my cloned server > >>>>> working in a vitual environment? > >>>>> > >>>>> Many thanks in advance, > >>>>> > >>>>> Kris. > >>>> > >>>> Well, sort of. Technically it's not supported in a virtual > >>>> enviroment, but other than a few issues, it works in one. FAX is > >>>> one of those that doesn't without extrodinary measures. > >>>> > >>>> Anyway, you can have only one copy of SBS2003 activated at a time. > >>>> You could install the eval version or do a fresh install from your > >>>> media and run in grace mode until activation is required. But to > >>>> move an activated copy to virtual requires that you reactivate the > >>>> close and cease using the original. > >>>> > >>>> If you are using sbsmigration you should be getting support > >>>> included with your purchase. Also use > >>>> microsoft.public.windows.server.sbs for standard product issues. > >>>> > >>>> -- > >>>> /kj > >>>> > >>>> > >>>> . > >> > >> -- > >> /kj > >> > >> > >> . > > -- > /kj > > > . > |
|
|
|
|
|||
|
|||
|
kj [SBS MVP]
Guest
Posts: n/a
|
Kris wrote:
> KJ, > > I managed to find a work around on the VMware forums, once again full > steam ahead ![]() Please share so others can benefit. > > Thanks for your help. > > Kris > > "kj [SBS MVP]" wrote: > >> It's that dang OEM software thing again. If the OEM didn't tie it to >> hardware you might technically get away with it, but if the same >> hardware wasn't running the virtualization server, then you wouldn't >> be legal. >> >> An approach might be to convert the OEM instance before you clone >> and move it. Reported methods have been to boot the VL media and do >> a repair on the OEM install but I can't personally confirm this and >> of course would highly recommend a full and complete verified backup >> before you start experimenting with your production instance. >> >> >> Kris wrote: >>> Hi KJ, >>> >>> Reactivation triggered by new hardware pretty much scraps my plans >>> if it cannot be reactivated, it would not have been an issue if >>> there was a grace period. The whole plan relied upon having a >>> clone of the existing server in a test environment, this would >>> allow me to test the migration in advance in a non production >>> environment. >>> >>> The hardware I have is as follows: >>> >>> Dell Poweredge 2600 running SBS 2003 (production server) >>> Dell Poweredge 2900(1) (test environment) >>> Dell Poweredge 2900(2) (test environment) >>> SAN for storing virtual machine images (either off the shelf or >>> Openfiler) >>> >>> The plan for the migration is (or was) as follows: >>> >>> Step 1: >>> >>> Convert Production SBS 2003 Poweredge 2600 to a virtual machine. >>> >>> Step 2: >>> >>> Copy Virtual machine created above to SAN in an isolated environment >>> >>> Step 3: >>> >>> Run cloned SBS 2003 on Poweredge 2900(1) running VMware ESXI >>> >>> Step 4: >>> >>> Clean virtual install of SBS 2003 on Poweredge 2900(2) running ESXI >>> >>> Step 5: >>> >>> Swing migration of Active Directory and Exchange from cloned SBS >>> 2003 install to clean SBS 2003 install. >>> >>> Step 6: >>> >>> Poweredge 2900(1) that was running cloned SBS will now provide high >>> availability incase Poweredge 2900(2) fails (the image that was >>> running on server 2 will be loaded on server 1) >>> >>> Step 7: >>> >>> Once I am confident everything works the old production Poweredge >>> 2600 will be utilised for backing up images etc (not running SBS) >>> >>> This plan/final topology provided the following advantages: >>> >>> 1) Migration can be practiced in advance >>> 2) Migration is performed in an isolated virtual environment >>> therefore no risk to >>> the production server. Once migration is complete the old >>> server can be removed from the network and the new servers >>> introduced therefore >>> virtually >>> zero downtime! >>> 3) Currently we have no budget and in theory the plan can be >>> practiced/proven without any expenditure ready for when funding >>> is available. This >>> relied upon >>> the clone working! >>> 4) Provides better disaster recovery than we currently have >>> 5) Removes software corruption issues present on the production >>> server 6) More ram/CPU can be assigned to SBS than is currently >>> available. The OS partition on the production server is 12gig >>> which causes issues, this >>> can be >>> resized as part of the physical to virtual machine conversion. >>> >>> Unfortunately the licensing seems to be introducing so many >>> barriers. I am now unsure about what licensing I need for the final >>> topology (image running on server 2 but server 1 incase of failure) >>> as well as the problem of what happens when the image loads up on >>> server 1, will I have the same issue as with my clone? >>> >>> Is there any work around for the issue with the clone as this is a >>> huge problem? >>> >>> >>> Regards, >>> >>> Kris >>> >>> >>> "kj [SBS MVP]" wrote: >>> >>>> Kris wrote: >>>>> Many thanks for your reply KJ. >>>>> >>>>> The clone was taken during the Christmas period, is it possible >>>>> the clones grace period has expired during the Christmas break or >>>>> is there no grace period with a clone? >>>>> I will try another physical to virtual conversion over the weekend >>>>> to confirm. >>>> >>>> Reactivation is triggered from the new hardware. >>>> >>>>> >>>>> I understand that I need a volume license as the final install >>>>> will be on a new server (no oem license) and the current sbs >>>>> install is a Dell OEM install. I am also planning to utilise the >>>>> high availability functionality available with VMware ESXI, will >>>>> this be an issue with SBS and the activation issues you mentioned? >>>>> >>>> >>>> Ah, OEM. Licensing is not your only concern. OEM built, cloned, and >>>> virtualized is still going to be an OEM install and retail or >>>> volume license keys are probably going to be another issue for you. >>>> >>>> You might consider doing a swing migration, perhaps a double swing, >>>> ending in a virtualized instance. www.sbsmigration.com >>>> >>>> Since you'll be having two seperate licenses, you could make this >>>> very invisible to the users. >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Kris >>>>> >>>>> >>>>> "kj [SBS MVP]" wrote: >>>>> >>>>>> Kris wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I would like to migrate our existing SBS2003 server to a fresh >>>>>>> SBS2003 install, I would also like to virtualise the server. >>>>>>> >>>>>>> I do not want to perform the migration in a live environment and >>>>>>> have decided the best/safest way to practice/carry out the >>>>>>> migration is in a virtual test environment. I am looking to >>>>>>> perform the migration using the documentation pack available >>>>>>> from sbsmigration.com >>>>>>> >>>>>>> I have managed to clone the existing server into a virtual >>>>>>> machine which is now isolated in a test environment. I would >>>>>>> like to migrate Active Directory and Exchange from this server >>>>>>> to a fresh SBS 2003 install. >>>>>>> >>>>>>> I was so excited when the virtual machine booted, then I logged >>>>>>> in to be prompted with the 'This product needs to be acivated' >>>>>>> dialogue box! >>>>>>> >>>>>>> I phoned Microsoft and entered the installation ID which was not >>>>>>> successful, I also spoke to a number of Microsoft >>>>>>> representitives after being cut-off a number of times and given >>>>>>> various numbers some of which did not work. Eventually I got >>>>>>> through to someone who informed me the product cannot be >>>>>>> activated as it is not licensed for use in a virtual >>>>>>> environment, although technical support may be able to help for >>>>>>> the small sum off £199 ![]() >>>>>>> >>>>>>> Can anyone advise me if it is possible to get my cloned server >>>>>>> working in a vitual environment? >>>>>>> >>>>>>> Many thanks in advance, >>>>>>> >>>>>>> Kris. >>>>>> >>>>>> Well, sort of. Technically it's not supported in a virtual >>>>>> enviroment, but other than a few issues, it works in one. FAX is >>>>>> one of those that doesn't without extrodinary measures. >>>>>> >>>>>> Anyway, you can have only one copy of SBS2003 activated at a >>>>>> time. You could install the eval version or do a fresh install >>>>>> from your media and run in grace mode until activation is >>>>>> required. But to move an activated copy to virtual requires that >>>>>> you reactivate the close and cease using the original. >>>>>> >>>>>> If you are using sbsmigration you should be getting support >>>>>> included with your purchase. Also use >>>>>> microsoft.public.windows.server.sbs for standard product issues. >>>>>> >>>>>> -- >>>>>> /kj >>>>>> >>>>>> >>>>>> . >>>> >>>> -- >>>> /kj >>>> >>>> >>>> . >> >> -- >> /kj >> >> >> . -- /kj |
|
|
|
|
|||
|
|||
|
Kris
Guest
Posts: n/a
|
Here is the link that helped resolve the issue:
http://communities.vmware.com/thread/251085?tstart=15 Kris "kj [SBS MVP]" wrote: > Kris wrote: > > KJ, > > > > I managed to find a work around on the VMware forums, once again full > > steam ahead ![]() > > Please share so others can benefit. > > > > > Thanks for your help. > > > > Kris > > > > "kj [SBS MVP]" wrote: > > > >> It's that dang OEM software thing again. If the OEM didn't tie it to > >> hardware you might technically get away with it, but if the same > >> hardware wasn't running the virtualization server, then you wouldn't > >> be legal. > >> > >> An approach might be to convert the OEM instance before you clone > >> and move it. Reported methods have been to boot the VL media and do > >> a repair on the OEM install but I can't personally confirm this and > >> of course would highly recommend a full and complete verified backup > >> before you start experimenting with your production instance. > >> > >> > >> Kris wrote: > >>> Hi KJ, > >>> > >>> Reactivation triggered by new hardware pretty much scraps my plans > >>> if it cannot be reactivated, it would not have been an issue if > >>> there was a grace period. The whole plan relied upon having a > >>> clone of the existing server in a test environment, this would > >>> allow me to test the migration in advance in a non production > >>> environment. > >>> > >>> The hardware I have is as follows: > >>> > >>> Dell Poweredge 2600 running SBS 2003 (production server) > >>> Dell Poweredge 2900(1) (test environment) > >>> Dell Poweredge 2900(2) (test environment) > >>> SAN for storing virtual machine images (either off the shelf or > >>> Openfiler) > >>> > >>> The plan for the migration is (or was) as follows: > >>> > >>> Step 1: > >>> > >>> Convert Production SBS 2003 Poweredge 2600 to a virtual machine. > >>> > >>> Step 2: > >>> > >>> Copy Virtual machine created above to SAN in an isolated environment > >>> > >>> Step 3: > >>> > >>> Run cloned SBS 2003 on Poweredge 2900(1) running VMware ESXI > >>> > >>> Step 4: > >>> > >>> Clean virtual install of SBS 2003 on Poweredge 2900(2) running ESXI > >>> > >>> Step 5: > >>> > >>> Swing migration of Active Directory and Exchange from cloned SBS > >>> 2003 install to clean SBS 2003 install. > >>> > >>> Step 6: > >>> > >>> Poweredge 2900(1) that was running cloned SBS will now provide high > >>> availability incase Poweredge 2900(2) fails (the image that was > >>> running on server 2 will be loaded on server 1) > >>> > >>> Step 7: > >>> > >>> Once I am confident everything works the old production Poweredge > >>> 2600 will be utilised for backing up images etc (not running SBS) > >>> > >>> This plan/final topology provided the following advantages: > >>> > >>> 1) Migration can be practiced in advance > >>> 2) Migration is performed in an isolated virtual environment > >>> therefore no risk to > >>> the production server. Once migration is complete the old > >>> server can be removed from the network and the new servers > >>> introduced therefore > >>> virtually > >>> zero downtime! > >>> 3) Currently we have no budget and in theory the plan can be > >>> practiced/proven without any expenditure ready for when funding > >>> is available. This > >>> relied upon > >>> the clone working! > >>> 4) Provides better disaster recovery than we currently have > >>> 5) Removes software corruption issues present on the production > >>> server 6) More ram/CPU can be assigned to SBS than is currently > >>> available. The OS partition on the production server is 12gig > >>> which causes issues, this > >>> can be > >>> resized as part of the physical to virtual machine conversion. > >>> > >>> Unfortunately the licensing seems to be introducing so many > >>> barriers. I am now unsure about what licensing I need for the final > >>> topology (image running on server 2 but server 1 incase of failure) > >>> as well as the problem of what happens when the image loads up on > >>> server 1, will I have the same issue as with my clone? > >>> > >>> Is there any work around for the issue with the clone as this is a > >>> huge problem? > >>> > >>> > >>> Regards, > >>> > >>> Kris > >>> > >>> > >>> "kj [SBS MVP]" wrote: > >>> > >>>> Kris wrote: > >>>>> Many thanks for your reply KJ. > >>>>> > >>>>> The clone was taken during the Christmas period, is it possible > >>>>> the clones grace period has expired during the Christmas break or > >>>>> is there no grace period with a clone? > >>>>> I will try another physical to virtual conversion over the weekend > >>>>> to confirm. > >>>> > >>>> Reactivation is triggered from the new hardware. > >>>> > >>>>> > >>>>> I understand that I need a volume license as the final install > >>>>> will be on a new server (no oem license) and the current sbs > >>>>> install is a Dell OEM install. I am also planning to utilise the > >>>>> high availability functionality available with VMware ESXI, will > >>>>> this be an issue with SBS and the activation issues you mentioned? > >>>>> > >>>> > >>>> Ah, OEM. Licensing is not your only concern. OEM built, cloned, and > >>>> virtualized is still going to be an OEM install and retail or > >>>> volume license keys are probably going to be another issue for you. > >>>> > >>>> You might consider doing a swing migration, perhaps a double swing, > >>>> ending in a virtualized instance. www.sbsmigration.com > >>>> > >>>> Since you'll be having two seperate licenses, you could make this > >>>> very invisible to the users. > >>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Kris > >>>>> > >>>>> > >>>>> "kj [SBS MVP]" wrote: > >>>>> > >>>>>> Kris wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> I would like to migrate our existing SBS2003 server to a fresh > >>>>>>> SBS2003 install, I would also like to virtualise the server. > >>>>>>> > >>>>>>> I do not want to perform the migration in a live environment and > >>>>>>> have decided the best/safest way to practice/carry out the > >>>>>>> migration is in a virtual test environment. I am looking to > >>>>>>> perform the migration using the documentation pack available > >>>>>>> from sbsmigration.com > >>>>>>> > >>>>>>> I have managed to clone the existing server into a virtual > >>>>>>> machine which is now isolated in a test environment. I would > >>>>>>> like to migrate Active Directory and Exchange from this server > >>>>>>> to a fresh SBS 2003 install. > >>>>>>> > >>>>>>> I was so excited when the virtual machine booted, then I logged > >>>>>>> in to be prompted with the 'This product needs to be acivated' > >>>>>>> dialogue box! > >>>>>>> > >>>>>>> I phoned Microsoft and entered the installation ID which was not > >>>>>>> successful, I also spoke to a number of Microsoft > >>>>>>> representitives after being cut-off a number of times and given > >>>>>>> various numbers some of which did not work. Eventually I got > >>>>>>> through to someone who informed me the product cannot be > >>>>>>> activated as it is not licensed for use in a virtual > >>>>>>> environment, although technical support may be able to help for > >>>>>>> the small sum off £199 ![]() > >>>>>>> > >>>>>>> Can anyone advise me if it is possible to get my cloned server > >>>>>>> working in a vitual environment? > >>>>>>> > >>>>>>> Many thanks in advance, > >>>>>>> > >>>>>>> Kris. > >>>>>> > >>>>>> Well, sort of. Technically it's not supported in a virtual > >>>>>> enviroment, but other than a few issues, it works in one. FAX is > >>>>>> one of those that doesn't without extrodinary measures. > >>>>>> > >>>>>> Anyway, you can have only one copy of SBS2003 activated at a > >>>>>> time. You could install the eval version or do a fresh install > >>>>>> from your media and run in grace mode until activation is > >>>>>> required. But to move an activated copy to virtual requires that > >>>>>> you reactivate the close and cease using the original. > >>>>>> > >>>>>> If you are using sbsmigration you should be getting support > >>>>>> included with your purchase. Also use > >>>>>> microsoft.public.windows.server.sbs for standard product issues. > >>>>>> > >>>>>> -- > >>>>>> /kj > >>>>>> > >>>>>> > >>>>>> . > >>>> > >>>> -- > >>>> /kj > >>>> > >>>> > >>>> . > >> > >> -- > >> /kj > >> > >> > >> . > > -- > /kj > > > . > |
|
|
|
|
|||
|
|||
|
kj [SBS MVP]
Guest
Posts: n/a
|
Kris wrote:
> Here is the link that helped resolve the issue: > > http://communities.vmware.com/thread/251085?tstart=15 > > Kris Thanks for posting back your discovery. > > "kj [SBS MVP]" wrote: > >> Kris wrote: >>> KJ, >>> >>> I managed to find a work around on the VMware forums, once again >>> full steam ahead ![]() >> >> Please share so others can benefit. >> >>> >>> Thanks for your help. >>> >>> Kris >>> >>> "kj [SBS MVP]" wrote: >>> >>>> It's that dang OEM software thing again. If the OEM didn't tie it >>>> to hardware you might technically get away with it, but if the same >>>> hardware wasn't running the virtualization server, then you >>>> wouldn't be legal. >>>> >>>> An approach might be to convert the OEM instance before you clone >>>> and move it. Reported methods have been to boot the VL media and do >>>> a repair on the OEM install but I can't personally confirm this and >>>> of course would highly recommend a full and complete verified >>>> backup before you start experimenting with your production >>>> instance. >>>> >>>> >>>> Kris wrote: >>>>> Hi KJ, >>>>> >>>>> Reactivation triggered by new hardware pretty much scraps my plans >>>>> if it cannot be reactivated, it would not have been an issue if >>>>> there was a grace period. The whole plan relied upon having a >>>>> clone of the existing server in a test environment, this would >>>>> allow me to test the migration in advance in a non production >>>>> environment. >>>>> >>>>> The hardware I have is as follows: >>>>> >>>>> Dell Poweredge 2600 running SBS 2003 (production server) >>>>> Dell Poweredge 2900(1) (test environment) >>>>> Dell Poweredge 2900(2) (test environment) >>>>> SAN for storing virtual machine images (either off the shelf or >>>>> Openfiler) >>>>> >>>>> The plan for the migration is (or was) as follows: >>>>> >>>>> Step 1: >>>>> >>>>> Convert Production SBS 2003 Poweredge 2600 to a virtual machine. >>>>> >>>>> Step 2: >>>>> >>>>> Copy Virtual machine created above to SAN in an isolated >>>>> environment >>>>> >>>>> Step 3: >>>>> >>>>> Run cloned SBS 2003 on Poweredge 2900(1) running VMware ESXI >>>>> >>>>> Step 4: >>>>> >>>>> Clean virtual install of SBS 2003 on Poweredge 2900(2) running >>>>> ESXI >>>>> >>>>> Step 5: >>>>> >>>>> Swing migration of Active Directory and Exchange from cloned SBS >>>>> 2003 install to clean SBS 2003 install. >>>>> >>>>> Step 6: >>>>> >>>>> Poweredge 2900(1) that was running cloned SBS will now provide >>>>> high availability incase Poweredge 2900(2) fails (the image that >>>>> was running on server 2 will be loaded on server 1) >>>>> >>>>> Step 7: >>>>> >>>>> Once I am confident everything works the old production Poweredge >>>>> 2600 will be utilised for backing up images etc (not running SBS) >>>>> >>>>> This plan/final topology provided the following advantages: >>>>> >>>>> 1) Migration can be practiced in advance >>>>> 2) Migration is performed in an isolated virtual environment >>>>> therefore no risk to >>>>> the production server. Once migration is complete the old >>>>> server can be removed from the network and the new servers >>>>> introduced therefore >>>>> virtually >>>>> zero downtime! >>>>> 3) Currently we have no budget and in theory the plan can be >>>>> practiced/proven without any expenditure ready for when >>>>> funding is available. This >>>>> relied upon >>>>> the clone working! >>>>> 4) Provides better disaster recovery than we currently have >>>>> 5) Removes software corruption issues present on the production >>>>> server 6) More ram/CPU can be assigned to SBS than is currently >>>>> available. The OS partition on the production server is 12gig >>>>> which causes issues, this >>>>> can be >>>>> resized as part of the physical to virtual machine conversion. >>>>> >>>>> Unfortunately the licensing seems to be introducing so many >>>>> barriers. I am now unsure about what licensing I need for the >>>>> final topology (image running on server 2 but server 1 incase of >>>>> failure) as well as the problem of what happens when the image >>>>> loads up on server 1, will I have the same issue as with my clone? >>>>> >>>>> Is there any work around for the issue with the clone as this is a >>>>> huge problem? >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Kris >>>>> >>>>> >>>>> "kj [SBS MVP]" wrote: >>>>> >>>>>> Kris wrote: >>>>>>> Many thanks for your reply KJ. >>>>>>> >>>>>>> The clone was taken during the Christmas period, is it possible >>>>>>> the clones grace period has expired during the Christmas break >>>>>>> or is there no grace period with a clone? >>>>>>> I will try another physical to virtual conversion over the >>>>>>> weekend to confirm. >>>>>> >>>>>> Reactivation is triggered from the new hardware. >>>>>> >>>>>>> >>>>>>> I understand that I need a volume license as the final install >>>>>>> will be on a new server (no oem license) and the current sbs >>>>>>> install is a Dell OEM install. I am also planning to utilise >>>>>>> the high availability functionality available with VMware ESXI, >>>>>>> will this be an issue with SBS and the activation issues you >>>>>>> mentioned? >>>>>>> >>>>>> >>>>>> Ah, OEM. Licensing is not your only concern. OEM built, cloned, >>>>>> and virtualized is still going to be an OEM install and retail or >>>>>> volume license keys are probably going to be another issue for >>>>>> you. >>>>>> >>>>>> You might consider doing a swing migration, perhaps a double >>>>>> swing, ending in a virtualized instance. www.sbsmigration.com >>>>>> >>>>>> Since you'll be having two seperate licenses, you could make this >>>>>> very invisible to the users. >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Kris >>>>>>> >>>>>>> >>>>>>> "kj [SBS MVP]" wrote: >>>>>>> >>>>>>>> Kris wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I would like to migrate our existing SBS2003 server to a fresh >>>>>>>>> SBS2003 install, I would also like to virtualise the server. >>>>>>>>> >>>>>>>>> I do not want to perform the migration in a live environment >>>>>>>>> and have decided the best/safest way to practice/carry out the >>>>>>>>> migration is in a virtual test environment. I am looking to >>>>>>>>> perform the migration using the documentation pack available >>>>>>>>> from sbsmigration.com >>>>>>>>> >>>>>>>>> I have managed to clone the existing server into a virtual >>>>>>>>> machine which is now isolated in a test environment. I would >>>>>>>>> like to migrate Active Directory and Exchange from this server >>>>>>>>> to a fresh SBS 2003 install. >>>>>>>>> >>>>>>>>> I was so excited when the virtual machine booted, then I >>>>>>>>> logged in to be prompted with the 'This product needs to be >>>>>>>>> acivated' dialogue box! >>>>>>>>> >>>>>>>>> I phoned Microsoft and entered the installation ID which was >>>>>>>>> not successful, I also spoke to a number of Microsoft >>>>>>>>> representitives after being cut-off a number of times and >>>>>>>>> given various numbers some of which did not work. Eventually >>>>>>>>> I got through to someone who informed me the product cannot be >>>>>>>>> activated as it is not licensed for use in a virtual >>>>>>>>> environment, although technical support may be able to help >>>>>>>>> for the small sum off £199 ![]() >>>>>>>>> >>>>>>>>> Can anyone advise me if it is possible to get my cloned server >>>>>>>>> working in a vitual environment? >>>>>>>>> >>>>>>>>> Many thanks in advance, >>>>>>>>> >>>>>>>>> Kris. >>>>>>>> >>>>>>>> Well, sort of. Technically it's not supported in a virtual >>>>>>>> enviroment, but other than a few issues, it works in one. FAX >>>>>>>> is one of those that doesn't without extrodinary measures. >>>>>>>> >>>>>>>> Anyway, you can have only one copy of SBS2003 activated at a >>>>>>>> time. You could install the eval version or do a fresh install >>>>>>>> from your media and run in grace mode until activation is >>>>>>>> required. But to move an activated copy to virtual requires >>>>>>>> that you reactivate the close and cease using the original. >>>>>>>> >>>>>>>> If you are using sbsmigration you should be getting support >>>>>>>> included with your purchase. Also use >>>>>>>> microsoft.public.windows.server.sbs for standard product >>>>>>>> issues. >>>>>>>> >>>>>>>> -- >>>>>>>> /kj >>>>>>>> >>>>>>>> >>>>>>>> . >>>>>> >>>>>> -- >>>>>> /kj >>>>>> >>>>>> >>>>>> . >>>> >>>> -- >>>> /kj >>>> >>>> >>>> . >> >> -- >> /kj >> >> >> . -- /kj |
|
|
|
|
|||
|
|||
|
|
|
| |
![]() |
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| sbs 2003 monitoring issue | tehmer | Windows Small Business Server | 2 | 01-13-2010 07:19 AM |
| sbs 2003 Monitoring reinstallation issue! | tehmer | Windows Small Business Server | 2 | 01-12-2010 11:31 AM |
| sbs 2003 r2 network issue | Jake | Windows Small Business Server | 3 | 01-10-2010 08:02 PM |
| Offline files fail to synchronize | Bob | Windows Vista File Management | 19 | 04-30-2009 04:45 AM |
| Vista Activation and Virtual Server VMs...? | Shepp | Windows Vista Installation | 8 | 02-11-2007 04:15 AM |
Forum Software Powered by vBulletin®, Copyright Jelsoft Enterprises Ltd.
SEO by vBSEO 3.3.2 ©2009, Crawlability, Inc. |



Linear Mode

