Slartibartfast

Their salesperson will never leave you alone if you express any interest. He will lie through his teeth to get you to sign on the dotted line. I would also be very sceptical of any claims they make about any school which is supposedly using the system.

70-292 is a complete bastard. I failed it last year with a score of 697, and eventually passed (just!) with a score of 700. I would advise reading the books for 70-290 and 70-291 in addition to 292. You may also find the 70-296 material useful.

Favourites are not stored in the 'Local Settings' folder, but in the root of the profile. They will roam quite happily. The folder can be redirected elsewhere with a registry change, but the shared folder solution would probably be less hassle.

Yes. There is also the User Profile Hive Cleanup Service which can be used in conjunction with that policy setting. The policy setting is at Computer Configuration->Administrative Templates->System->User Profiles->Delete cached copies of Roaming Profiles User Profile Hive Cleanup: http://www.microsoft.com/downloads/details.aspx?FamilyID=1b286e6d-8912-4e18-b570-42470e2f3582&DisplayLang=en

The thing to remember about 70-292 is that it's essentially 70-290 and 70-291 crammed into one exam.

Congratulations! It was a complete bastard of an exam when I did it a couple of years ago.

When I originally tried to set this up with a basic 'Domain User' account, it worked, but rather inconsistently. For example, users could be added to the 'cache' group, but wouldn't be able to authenticate for another 24-48 hours. Adding the 'cacheadmin' account to the 'Domain Admins' group seems to solve all the quirky problems, although it's not the solution I would like.

Yes. Try making the cachepilot LDAP user account a member of 'Domain Admins'. If that doesn't work straight away, try these instructions: 1.Create a group in AD called 'cache'. 2. Create a user in AD called 'cacheadmin' in the 'Users' container. This account needs to be a member of 'Domain Admins' and the 'Cache' group created earlier. 3.On the cachepilot LDAP configuration page, configure the settings as follows: LDAP Server: IP address of DC. User Directory: Base DN of AD Domain (e.g. DC=reephamhigh,DC=local) User: cacheadmin, CN=Users Password: password for cacheadmin 4.On the cachepilot 'User' page, add a user called 'cache' (the same as the AD group created earlier) and make the user a member of the cachepilot 'controlled' group. 5.On the cachepilot 'Web Access' page, change the radio button to 'Users'. 6.In Active Directory, user accounts need to be added to the 'cache' group to be able to authenticate and access the internet. Issues: UPN suffixes are not supported. Users that have been renamed in the past cannot authenticate. Users with spaces or other non-alphanumeric characters in their passwords cannot authenticate.

I would also suggest having profiles and documents on different partitions, but it really depends on whether you want their profile to be included in their disk quota or not. If you have 2003 R2, you can probably ignore this suggestion and just use the more flexible quota management tools included with that.

There's an IAS remote access policy in place to prevent this. Exactly. User accounts need to be a member of a specific group to authenticate.

Are the proxy settings set in the User or Computer area in the GPO? Try a full group policy synchronisation (gpupdate /sync from the command prompt) and reboot. Also, check the output of gpresult for any 'Access Denied' or similar messages. They could indicate a problem with the Active Directory machine account.

We use Server 2003 with IAS to authenticate all of our wireless clients. After some unsuccessful experiments with certificates, we decided to use PEAP for authentication. The advantage (to us) is that machines with Active Directory computer accounts authenticate themselves. Laptops which are not domain members are prompted for a domain username and password to connect to the wireless network.

Yup.

In the application event log... Event ID: 329 "Synchronization failed. Reason: The underlying connection was closed: Unable to connect to the remote server.." In WSUS itself: "There was an error communicating with the upstream server. Please check your update source and proxy server settings on the Synchronization Options page." Proxy settings are all configured correctly. SUS and everything else works perfectly. The proxy logs are showing attempted SSL connections to update.microsoft.com on port 443.

I'm not having any luck with it at all. It's doesn't seem to like our Equiinet proxy/cache. SUS works perfectly.