System Management

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

Do you know how Microsoft IT manages thousands of servers worldwide in multiple countries for a large number of departments and customers using SCCM 2007?
If no, then you should listen to this 30 minutes podcast: Microsoft IT Business Case for System Center Configuration Manager 2007 in a Data Center.

And here is the full article about this business case. I found it very interesting…

My last post (Using Group Policy to deploy Office 2007) was quoted on TechEdBloggers site.

Last week I tested how Office 2007 installs via Group Policy.

I created a software installation package and it worked successful; except the fact that it is not fully installed when a user logs on and that it will not upgrade (or remove) the existing version of Office even if I added the Office 2003 package that should be upgraded. After the Office 2007 installs, the users will have both version of Office – 2007 and 2003.

This is because Microsoft changed a little the way Office 2007 installs; and here they explain why they did this. Bellow are some considerations from that article:

• Difficulties with scheduling installation, consistently managing network bandwidth, and providing feedback on the status of the installation.
• Limited ability to customize features or user settings before installation of the 2007 Office system. You cannot use Office Customization Tool to create an .msp file. All customizations have to be made in the Config.xml file.

So, the best way to install Office 2007 in a medium organization is to use System Center Essentials or Configuration Manager in a large organization. Using these tools you can know exactly what features to install, when to install and how to install or upgrade Office 2007 suite.

Something I have learned the other day…

I had to install a small .msi using Group Policy, using a logon script. As it was a small package and not very important, I used a User Configuration Logon script.

I created and linked a new GPO to a specific OU with some users (with no admin privileges) and client computers only. The script run well and the package installed very quickly on all machines in that OU.

The problem was that I have another OU with member servers and at the moment I logged on to one server using a normal user account, I had the package installed right after first logon. This is because I configured User Configuration logon script instead of Computer Configuration startup script.

What I’ve learned? That I should plan more careful even the installation of a small package.

In case you have PXE Boot working normally but suddenly it is not working anymore, it may be because of the WDS service. This might sound strange but sometimes Windows Deployment Services (WDS) Server does not start after restarting the server, even if it is set to automatically start. It happened to me a few times….

Starting the service fixed the problem (in my case) every time. I didn’t tried, but maybe configuring delayed start for this service will fix the problem in the future.