System Management

Yesterday I was trying to install a network printer on Windows Server 2008 system. After typing printer’s IP address, I received an “Access denied” error.

The problem was that I tried to install the printer while I was logged on with a user that had domain admin privileges, but not the default domain Administrator account.
When I logged in with domain admin user – Administrator – I was able to install the printer successfully.

Searching the internet, I saw that some people are saying that this error appears only when having UAC turned on.

Today I learned again a lesson I knew for some time but was hoping that I can forget it. The lesson was about: “Trust anyone. Test for yourself.”

Having to install WSUS on a remote SQL 2005 that had WSUS database installed before, I asked one SQL guy if renaming the old WSUS database is enough to install a new WSUS one. He said yes. Ok then, I started installing WSUS.

Needless to say, installation failed:

There is a problem with the windows installer package.A program run as part of the setup did not finish as expected.Contact your support personnel or package

Two hours of troubleshooting permission and connection problems, made me read all WSUS installation log files located in “X:\Users\username\AppData\Local\Temp”. One of the file was 1 KB size so it does not contain much info. Anyway, the file content was:

Changed database context to 'master'.
Msg 1802, Level 16, State 4, Server SQL-SERVER-NAME,  Line 2
CREATE DATABASE failed. Some file names listed could not be created. Check related errors.Msg 5170, Level 16, State 1, Server SQL-SERVER-NAME,  Line 2
Cannot create file 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\SUSDB.mdf' because it already exists. Change the file path or the file name, and retry the operation.
Changed database context to 'master'.

I will not comment the 4^th line as it says pretty much all…

I guess when doing something, you have to test for yourself everything. Lesson learned. Again.

Today a client called me and said that his second domain controller, which is on Hyper-V, is having connectivity problems. For example, running the ping command from DC2 results in very bad response times or timed out requests.

Searching the event viewer, I saw many errors with Event ID 1054: “Description: Windows cannot obtain the domain controller name for your computer network. (The specified domain either does not exist or exist or could not be contacted). Group Policy processing aborted.”

Found a Knowledge Base article on Microsoft website that basically says this is happening if the computer has some AMD technology enabled in the BIOS. Well, my client only has computers with Intel Xeon processors, so this is not the case. Anyway, having experience with such articles vs. errors, I read the article till the end. This way I found similarities with my client’s environment: computers with more than one processors.

Basically, Dual Core or multiprocessor processors may encounter Time Stamp Counter (TSC) drift if certain conditions are met:

• number of processors
• operating system
• technologies enabled in the BIOS
• BIOS version.

This conditions can affect important operations like network communications and performance monitoring tasks that are sensitive to system time

Windows XP, 2000 and 2003 servers use the TSC as a timekeeping source. Each processor core (whether it is a single-core processor or dual-core processor) includes a TSC. When the TSC for different processor cores are not synchronized, the above symptoms and behaviors can occur if the operating system is using the TSC as a timekeeping source.

The KB article’s resolution is to install a newer CPU driver that modifies the boot.ini file by adding a switch in order to force the computer to use the PM_Timer instead of TSC. Also, it says that the boot.ini file can be manually modified.

So, to manually modify boot.ini file follow the following steps:

• Log on to the computer by using an account that has administrative credentials.
• Click Start, click Run, type notepad c:\boot.ini, and then click OK.
• In the Boot.ini file, a line that starts with "default" is located in the "[boot loader]" section. This line specifies the location of the default operating system. The line may appear as follows:

  multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows Server 2003 Enterprise x64 Edition" /fastdetect /NoExecute=OptIn

• At the end of the line, add a space, and then type /usepmtimer. The line should now resemble the following.

  multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows Server 2003 Enterprise x64 Edition" /fastdetect /NoExecute=OptIn /usepmtimer

• Save the file, and then exit Notepad.
• Restart the computer

This resolved the connectivity problem, however I wanted to test one more thing. As DC2 where a virtual machine with 2 cores assigned, I changed it to use only one processor and modified the boot.ini file to its original state. After restarting the VM and monitoring the server for bout 20 minutes, looks like the problem went away. So this can also be a workaround. I used the first method as client preferred this one.

These are the articles I read carefully today and used now to write this post:

• Programs that use the QueryPerformanceCounter function may perform poorly in Windows Server 2000, in Windows Server 2003, and in Windows XP: http://support.microsoft.com/kb/895980
• Explanation for the USEPMTIMER switch in the boot.ini: http://blogs.technet.com/perfguru/archive/2008/02/18/explanation-for-the-usepmtimer-switch-in-the-boot-ini.aspx

Short post that I think might be useful…

If you receive the following error: “An error occurred while retrieving policy for this computer (0x80072EE7)” when Task Sequence Wizard starts, this can happen if you have DHCP or DNS problems.

You should check if you can contact the DHCP server in order to get an IP address or you can configure a static IP address.

If you have a switch with STP enabled, you might want to read this post.

Let’s suppose you create a package with one program and want to advertise it only to a few selected platforms, including x86 and x64 Windows 7 systems. Because Windows 7 is not supported yet with Configuration Manager 2007 SP1, you cannot choose it from the supplied list of platforms. As a result of this, after receiving and downloading the package, the system will give you the following message:
Program rejected (wrong platform). Advertisement "XYZ12345" from site "XYZ" was rejected because the client's platform is not supported.

It is expected that SP2 will add support for Windows 7, but until then we can use the following workaround:

1. Create a collection with all Windows 7 systems
   select sms_r_system.ResourceID, sms_r_system.ResourceType, sms_r_system.Name, sms_r_system.SMSUniqueIdentifier, sms_r_system.ResourceDomainORWorkgroup, sms_r_system.Client from sms_r_system where OperatingSystemNameandVersion like '%Workstation 6.1%'
2. Create a new program (for example Program for Win7) for the same package and select “This program can run on any platform” as a requirement.
3. Create a new advertisement and use “Program for Win7” program. Advertise it to Windows 7 collection created earlier.

That’s it. This may not be the best workaround, but it worked very well for me, at least until SP2 will RTM and I can install it in production.

Usually, extending the Active Directory schema is the last step I do when installing SCCM. This time, while installing SCCM in a virtual machine, you have to provide a path to a folder with SCCM updates or download these updates from the internet. Working in a virtual machine with a “Local only” network adapter, I couldn’t download those updates; so I switch the network adapter to an external one. After downloading the updates, next step is “Installation Prerequisite Check” and at this step I extend the AD schema.

Well, the following error was written in ExtADSch.log file:
Unable to connect to RootDSE - Cannot update Active Directory. Error code = 1355.
Failed to extend the Active Directory Schema.

Error 1355 is: ERROR_NO_SUCH_DOMAIN. That means that the specified domain could not be contacted or does not exist. The problem here is that I did not switched back to “Local only” network adapter and so the Active Directory could not be contacted. Setting the adapter to “Local only”, I could contact the Domain Controller and extending the schema was successful.

Someone just asked how to create a collection with all laptop computers? Well, if there is a good naming convention on site, this query will be easy to make even for me But, otherwise, we need to use chassis type value because laptops and notebooks are not the same things.

The full list with chassis types are bellow (taken from http://www.microsoft.com/technet/scriptcenter/guide/sas_cpm_btnz.mspx?mfr=true):

So, to make a collection with all kind of mobile systems (Portable, Laptop, Notebook, Sub Notebook) we will use 8, 9, 10 and 14 chassis types. The final query looks like this:

select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SYSTEM_ENCLOSURE on SMS_G_System_SYSTEM_ENCLOSURE.ResourceID = SMS_R_System.ResourceId where SMS_G_System_SYSTEM_ENCLOSURE.ChassisTypes in ("8", "9", "10", "14")

If you receive the “This query has a syntax error.” error, change the quotation marks when pasting the query, as this one does not work with ConfigMgr.

Suppose you have created a task sequence, advertised it and booted from task sequence media or however you want; if you receive the following error: “Task Sequence: <TS name> has failed with the error code (0×80004005). For more information, please contact your system administrator or helpdesk operator.” at Setup Windows and ConfigMgr step you might want to check the Product Key! Most probably the key is not correct, so either write another one or remove the product key at all from Apply Windows Settings step in your task sequence and you will have to provide it during the install phase.

I left the product key blank and next time I booted the PC from the TS media, at the Setup Windows and ConfigMgr step I was asked to provide a product key. I entered my Business edition product key and everything was ok.

A few days ago I had to make an image with Windows XP SP3 with all needed applications for lite touch installation.

Everything went well and I was happy until I entered the mini-setup phase on the first computer with that image applied on it. I received an error regarding the product key. I guess I tried a dozen of product keys but none of them worked. After reading the message again and more careful, I realized that the problem was with my Windows XP media – it was not a VL media. And I realized this because the message said to look for a product key on the Certificate of Authenticity (COA) sticker and not my License Agreement…

Resolution

Got another media with Windows XP SP3 VL and made a repair. During the repair phase, I provided the VL product key and it worked. Next time I entered the mini-setup, I filled in some info and that was it.

I just spent half an hour trying to understand why my task sequence cannot find the files on a distribution point; although the TS runs normally, I see all available TSs and I can choose the one I need. Then I found why: I missed something I never missed before and that must not be forgotten! I forgot to configure the network access account .

So, if you receive the following error: “This task sequence cannot be run because the program files for <your package here> are inaccessible on the distribution point.”

you should check if your network access account are configured and the information is correct.

To resolve this issue, you must correctly configure the System Center Configuration Manager 2007 client network access account. To do this, follow these steps:

1. Use an account that has administrative permissions to log on to a computer that has the System Center Configuration Manager 2007 Administrator Console installed.
2. Click Start, click All Programs, click Systems Management Server, and then click SMS Administrator Console.
3. Expand ServerName, expand Site Management, expand SiteName, and then expand Site Settings.
4. Click Client Agents, right-click Computer Client Agent, and then click Properties.
5. In the Computer Client Agent Properties dialog box, next to the network access account that you want to configure, click Set.
6. In the Windows User Account dialog box, enter the user name and the password that you want to use for the network access account, and then click OK two times.

Here is Microsoft’s article about this: http://support.microsoft.com/kb/935914