It is becoming more and more apparent that "experienced" system, network, and desktop administrators (meaning they have been on the job for many years) have developed an attitude towards new technology and software where they think they are 'the man' or believe they are 'know-it-alls' and don't bother to train, document, or fully test the new software FOR their end users. Support calls flow into the helpdesk or Service Desk primarily due to a lack of planning. And planning, ladies and gentleman, SHOULD BE your primary concern when expecting to implement new technology in the corporate environment. Now, of course, I don't intend to generalize my ideas on every single admin because I KNOW my statements to not apply to every single one of them. But in my experience, 90% of the admins I have had to deal with have this mentality, which I do not appreciate. Anyways, on with the point of my post....
With new versions of software, especially in Microsoft's case, the software developer usually makes changes to how the software works, or how security functions in the new software, and brings new compatibility issues with current client or server designs. Cases in point, Internet Explorer 7 and 8, Office 2007, and Windows 7.
Problem #1: I received a phone call from a user that is getting annoyed with Internet Explorer 8 on their Windows 7 computer because it keeps on asking for his user credentials even though it is an intranet site (for this example lets say the site is site1.contoso.local). I used a remote tool to take control of his windows session and I added the website as a trusted site in the Internet Sites list. Even though I did that, IE still asked for credentials. So instead, I added the site as a trusted Intranet (not Internet) site, which IE prompted me that if I wanted to continue it would move the site to the intranet sites from the trusted internet sites. Obviously I clicked OK. Now that the intranet site opens just fine they tried to open a Word doc hosted on the page, but when opening the document, Microsoft Word 2007 was demanding credentials to view the file! The user made the changes he wanted then saved, but Word 2007 again asked to save the file. That is 3 logins just to do his work! Not worrying about the Word 2007 login annoyance, I continued looking at the problems this user was experiencing. Now the user wanted to go to another intranet site such as site2.contoso.local, IE prompted for credentials again. Instead of adding site2.contoso.local I attempted to add the domain by defining "http://*.contoso.local"
Microsoft changed their entire security model regarding Trusted Internet Sites and Intranet Sites for Internet Explorer 7 and Internet Explorer 8 and Office 2007. If the website as a 'dot' in it, meaning Microsoft.com or Contoso.local, the browser will not pass credentials to the web server automatically because it believes that this is an internet website, not an intranet hosted site. In Office 2007 applications, there is a feature called the "Trust Center" that does the EXACT SAME thing that Internet Explorer does. Adding the website as a trusted intranet site solves the problem, but only for that one website. I needed to add the additional websites so the user wasn't constantly probed for credentials.
There are 2 fixes to this problem:
Option #1 is to simply add the sites manually as intranet sites in Internet Explorer, and add the sites as intranet sites in the Trust Center in Office 2007 applications. Option #2, just make a friendly DNS alias per site; for example "site1" that points to "site1.contoso.local" or "site2" that points to "site2.contoso.local". Option 2 was the best course of action because of the level of impact that this issue could have. But as we all know, even if a little change is the best course of action System and Network Admins don't like change – especially if the change recommendation comes from level one support. The admins didn't bother looking into the issue until they experienced the same issue on their own.
Problem #2:
User calls the Service Desk and asks to map a network printer on her Windows 7 computer. I remote into her Windows session to help. I searched for the network printer and added it, but Windows stopped the driver installation and said that only Administrators can install drivers on the computer. The user had a windows XP computer last week and they were able to add printers at any time. What is going on and how can I fix it?
Solution one is to use the Windows 7 "switch user" feature and log in with admin rights, then map the same printer on your own which will install the driver on the computer. Log off of the computer, have the and allow the user to map the printer when they log in themselves. Solution two is to upgrade Group Policy ADM and ADMX files for Windows 7 and Windows Server 2008 R2 support on the domain controllers then modify both User and Computer Point and Print Restrictions to allow for users to install print drivers. Solution one is a workaround, solution two is the permanent fix.