Enterprise conversion from XP to Win7

[Diabolus]

I know many of you are in the IT world and I am in need of some help.

I'm trying to better understand the pain points when migrating from XP to Win7, including an upgrade from Office 2003 to Office 2010.

I'm looking more from the end-user perspective, and any issues the end-user would experience on the new Win7 and Office 2010.

I'm concerned with everything, including issues with converting Excel 2003 to 2010, especially so with macros.

Any help, resources, or your experience would be a massive help.

Thanks

[SouperMan]

Are you planning to go 64-bit Windows 7 and/or 64-bit Office 2010?

I noticed that a lot of custom built VBA scripts and some Access Databases would not run until I recompiled it in Office 2010.

If you are super concerned about Office compatibility, you may use Windows XP Mode which will create a virtual instance of Windows XP
and install apps that won't work in Win7.

Sent from my mobile using Tapatalk

[Montu]

I've also noticed the VBA script issue

[NytWolf]

Most vb script macros created in Office 2003 will run in Office 2010, which is better than 2007. Those that don't run will need to be recreated.

I wouldn't recommend running programs in XP compatibility mode. Why even upgrade to Win7 then? Also, I do not recommend going to 64-bit Win7 unless you absolutely have to. Most applications that exist are still 32-bit anyway. Not only will they run faster in the 32-bit OS, you won't have to resort to the compatibility mode.

[odysseus]

Curious, when you say "enterprise", how large are we talking? How many systems and users?

[meaty-btz]

Most vb script macros created in Office 2003 will run in Office 2010, which is better than 2007. Those that don't run will need to be recreated.

I wouldn't recommend running programs in XP compatibility mode. Why even upgrade to Win7 then? Also, I do not recommend going to 64-bit Win7 unless you absolutely have to. Most applications that exist are still 32-bit anyway. Not only will they run faster in the 32-bit OS, you won't have to resort to the compatibility mode.

WAT? (yes spell correctly)

You have no idea how x64 vs x32 operates in an Enterprise Environment. The only time x32 is an advantage is when hacking older drivers to force them to be used by windows 7 and said drivers were only available in 32-bit (xp and early vista) . This is NOT a good thing to do in the first place and any hardware that requires such should be retired by any sane enterprise. No 32bit programs run faster on x32 vs x64 versions of windows because x64 has full compatibility with 32-bit libraries and therefor programs. In fact many newer enterprise software IS 64-bit.


You should have a migration roadmap. If you don't make one. It should include the companies normal hardware cycle (usually 36months) and should be situated on said cycle in such a way as to retire old and incompatible hardware in such a way as to ease migration.

If you want more from me you are going to be paying me $$ for that information. Not to be harsh but what I have learned migrating over 100 servers, our domain, our exchange server, our virtual machines, our VDI, our 6000 desktops over to windows 7 was hard earned and worth its weight in gold.

[SouperMan]

WAT? (yes spell correctly)

You have no idea how x64 vs x32 operates in an Enterprise Environment. The only time x32 is an advantage is when hacking older drivers to force them to be used by windows 7 and said drivers were only available in 32-bit (xp and early vista) . This is NOT a good thing to do in the first place and any hardware that requires such should be retired by any sane enterprise. No 32bit programs run faster on x32 vs x64 versions of windows because x64 has full compatibility with 32-bit libraries and therefor programs. In fact many newer enterprise software IS 64-bit.


You should have a migration roadmap. If you don't make one. It should include the companies normal hardware cycle (usually 36months) and should be situated on said cycle in such a way as to retire old and incompatible hardware in such a way as to ease migration.

If you want more from me you are going to be paying me $$ for that information. Not to be harsh but what I have learned migrating over 100 servers, our domain, our exchange server, our virtual machines, our VDI, our 6000 desktops over to windows 7 was hard earned and worth its weight in gold.

^^^Yup^^^

We got some old hardware that needs to interface with a data logger that still requires Windows XP, and trying to keep a old Optiplex 260 running was no longer feasible, so the first instance we got we moved with Windows 7 with Windows XP Mode enabled. Until we get the $$$$ to replace the hardware and data logger, Windows XP Mode will stay on.

With 64-bit you get to use 8GB+ of RAM and get to take better advantage of multi-threaded apps.

We are getting ready to deploy Windows 7 from SCCM onto our production environment after weeks of testing, I can feel the pain meaty-btz.

Sent from my mobile using Tapatalk

[hcbr]

Right now where i work, we're doing Vista to Win 7 (actually before we did XP to Vista).

I know it seems we did the wrong thing with Win 7 but doing the upgrade to Vista helped us alot to understand how we did our migrations.

I can tell you that the first things we did was a 6 month pilot to test ALL apps with every application manager in our organization. Our key thing was before upgrading was to see which apps would have an impact and if there was any incompatibility. If so, we would identify any issues, and address them with either patches, workarounds, or upgrades.

That was our first phase with our lab, the second phase was to have an open pilot, to choose several users from each dept. and have them test it. The key thing is the users experience. We made sure that the users tested their pilot machines in a real environment. Data migration and upgrading their machines to Vista was effortless, and we were able to do this by having our helpdesk do this in different deployments.

Overall our deployment to upgrade to Vista was about 1 year for 1500 machines. This included testing of apps and upgrading machines or replacing machines.

Now we enter Windows 7 upgrading, which we learned that using WOL and using distribution and management apps like Zen works (yes i know we still use GroupWise here, which I frankly hate since my background is in pure windows) but we are able to do over the wire migrations.

As for 32 or 64 bit, you're better off sticking with 32 bit, i hate to say it but not everything out there has really made the leap to make everything 64bit.

As for office 2003 , we upgraded to 2007 due to macro's , and we haven't upgraded to 2010 yet, but will be since MS has done their part to make sure our macro related content is compatible.

[NytWolf]

If you want more from me you are going to be paying me $$ for that information. Not to be harsh but what I have learned migrating over 100 servers, our domain, our exchange server, our virtual machines, our VDI, our 6000 desktops over to windows 7 was hard earned and worth its weight in gold.

No thanks. We already paid Microsoft to come in and do a thorough evaluation. They told us that unless all our applications were already 64-bit, we are advised to stay with the 32-bit OS.

In your case, your entire domain sounds like it's already 64-bit. For us, the only thing we have 64-bit on the client side is AutoCAD. Our server pool is 75% 64-bit.

[Peter.Steele]

No thanks. We already paid Microsoft to come in and do a thorough evaluation. They told us that unless all our applications were already 64-bit, we are advised to stay with the 32-bit OS.

In your case, your entire domain sounds like it's already 64-bit. For us, the only thing we have 64-bit on the client side is AutoCAD. Our server pool is 75% 64-bit.

Okay, sorry, but this sounds like a complete and utter pant load.


1. 32 and 64 bit versions of Windows are on the same disk, even if you have an enterprise serial number.

2. If you're only doing MS Office stuff, you're not going to notice any theoretical difference in performance between 32- and 64-bit versions of the OS anyway, so it's not that 32-bit is faster so much as that it just doens't ****ing matter.

3. If anyone in your workgroup is using anything that would benefit from 64-bit, then why in the **** are you even considering not going 64-bit?

4. Did you check the company ID's from the people from Microsoft? Were they made with crayon?

[NytWolf]

Okay, sorry, but this sounds like a complete and utter pant load.


1. 32 and 64 bit versions of Windows are on the same disk, even if you have an enterprise serial number.

2. If you're only doing MS Office stuff, you're not going to notice any theoretical difference in performance between 32- and 64-bit versions of the OS anyway, so it's not that 32-bit is faster so much as that it just doens't ****ing matter.

3. If anyone in your workgroup is using anything that would benefit from 64-bit, then why in the **** are you even considering not going 64-bit?

4. Did you check the company ID's from the people from Microsoft? Were they made with crayon?

Mmmmmkay?

[meaty-btz]

Okay, sorry, but this sounds like a complete and utter pant load.


1. 32 and 64 bit versions of Windows are on the same disk, even if you have an enterprise serial number.

2. If you're only doing MS Office stuff, you're not going to notice any theoretical difference in performance between 32- and 64-bit versions of the OS anyway, so it's not that 32-bit is faster so much as that it just doens't ****ing matter.

3. If anyone in your workgroup is using anything that would benefit from 64-bit, then why in the **** are you even considering not going 64-bit?

4. Did you check the company ID's from the people from Microsoft? Were they made with crayon?

This.

No, most of our applications were 32-bit with more going 64-bit every year. There are CRITICAL things you need to have in order and questions answered before you begin your migration. Moving to Windows 7 is NONTRIVIAL. How about your domain? Are you on server 2008R2? Is your domain ready for Windows 7? If not, you really need to get ready for it. A ton changed and how you do things have changed. Item Level Targeting, various oddities in how GPO's apply. Printer mapping gotcha's. User share issues. It is HUGE just preparing and migrating from a Server 2003 to a windows 7, Server 2008R2 domain (64-bit only btw so you will need servers that support it). How about your Exchange Server, did you know there are critical issues and alterations that have to be solved when migrating your Exchange Server? Did you know running Server 2008R2 Domain pretty much requires you to update your Exchange Server or all kinds of weird things can go wrong?

Hardware, compatible with windows 7? Sure, we have several thousand HP desktops have 100% drivers for Windows 7 and are in use and deployed. Did you know, however, that the front audio out ports are NON-FUNCTIONAL under windows 7? Yeah, who knew...

How about machine imaging, changes here as well. New options and new gotcha's.

DO you have a roadmap?

Legacy Applications?

Seriously this is a non-trivial thing in any REAL enterprise environment. We began our migration almost two years ago with back-end upgrades and then slowly but surely got into compliance and then THIS Fall we began major desktop migration. The process will not be completed until well into next year.

[the86d]

The only difference we have noticed is that (as we don't use a bunch of custom scripts) drivers for old peripherals that you may wish "not upgrade" (desktop scanners, desktop printers, and proprietary devices such as digital Voice Memo Recorders [HR has some funny ideas]) may not have 64 bit drivers.

Windows 7 still drags it's feet sometimes, like Vista, and you are wondering if it even took the action you just selected. Then 10 seconds later it catches up, even on dual to quad core machines.

An other thing that irks me is that Windows 7 functions, yet they have not addressed the "Right-Click" issue. You can right click a file and not get all your menu options. then you click the file, right-click it again and you can get the correct menu.

Make sure to remove the old host from the Domain, if you are to reuse the hostname, or if you are running 3rd party AV software/content filters and such can have issues with 2 computers with the same hostname not able to join it to the Domain. (The old doesn't go away and the AV server doesn't know how to deal with a new computer with the same host name on Symantec, or Kaspersky. You might have to Manually remove hosts from an AV server for hostnames to function. Let's not talk about issues with RENAMING a host connected to the above mentioned AV servers...)

[JDay]

Most vb script macros created in Office 2003 will run in Office 2010, which is better than 2007. Those that don't run will need to be recreated.

I wouldn't recommend running programs in XP compatibility mode. Why even upgrade to Win7 then? Also, I do not recommend going to 64-bit Win7 unless you absolutely have to. Most applications that exist are still 32-bit anyway. Not only will they run faster in the 32-bit OS, you won't have to resort to the compatibility mode.

32-bit apps run just fine in 64-bit Windows. Not to mention that 64-bit Windows 7 is more secure.

[meaty-btz]

32-bit apps run just fine in 64-bit Windows. Not to mention that 64-bit Windows 7 is more secure.

Your comment made me wonder. Do most people know about the massive security hole the size of a school bus that Windows 7 32-bit has? I would assume no because it has not been "fixed".... When we discovered it, we went panic mode. One more reason to go full 64-bit Windows 7. We used GPOs to disable the security issue. Microsoft's response was laughable to our report, it is supposed to be there for legacy support. You mean it? You really do? You mean you intentionally put something into professional enterprise software that allows unauthenticated authoritative execution of certain commands from a remote computer to nearly any computer on that domain?!?!?