Great article by Steve Rachui on creating a web page so that config choices can be made without needing access to the SCCM Console. Example and scripts are included
Get it here
Monday, 23 August 2010
Saturday, 14 August 2010
Images : File based Vs Sector Based; What's Best?
Good Series of blog posts over on the Springboard blog detailing a for / against comparison for the various deployment methods
Part 1 : The terms and WIndows tools primer
Part 2 : The pros and cons
Part 3: Deploy-time Build Automation and Recommendations
Friday, 13 August 2010
Thursday, 12 August 2010
Core Configurator 2.0 released
Core Configurator 1.0 was a god-send when setting up my Win 2008 R2 Server Core Hyper-V cluster. v 2.0 has been released and looks even better, due to it being written in Powershell 2 and uses Winforms, to give it that GUI some people seem to like :)
Wednesday, 11 August 2010
Getting Google Calendar Sync tool working with Outlook 2010
This one requires a bit of hacking using a hex editor, so only do it if you feel confident/competent/brave enough to do :)
You'll need HxD for this one.
And instructions are here http://www.addictivetips.com/microsoft-office/sync-google-calendar-outlook-2010-quick-fix/
You'll need HxD for this one.
And instructions are here http://www.addictivetips.com/microsoft-office/sync-google-calendar-outlook-2010-quick-fix/
ConfigMgr OSD: Always including certain files in your Boot Images -think Trace32
From 1e.com. How to include files in your OSD boot images
SCCM 2007 : OSD build and capture Task Sequence fails when applying OS
Found a great article when researching a problem I had trying to run a Build and Capture task sequence in SCCM 2007 SP2. Basically, when the sequence comes to apply the image, if the advertisement is set to run from the DP, it will fail with a 0x80004005 error. This is due to a NIC driver being installed, thus breaking the connection to the DP. One solution is to set the advertisement properties to download the content locally from the Distribution Points tab.
Article
Article
Wednesday, 4 August 2010
Monday, 2 August 2010
Windows : Account Lockout Tools
Just had a nice error that had me a little stumped. I changed the password on the admin account that I use on to remote on servers around site, but it kept locking out. I've never had the problem before, so I was a little peeved. Anyway, using a combination of the linked Account Lockout Tools and Event Viewer on the originating DC to search for event 644 (User account successfully locked out), I managed to trace down the originating server.
1. From the extracted download, run LockoutStatus.exe
2. type in user to query
3. Check if account is locked. If it is, check Orig Lock column to determine DC that locked account
4. Connect to Security log of the DC in question
5. Filter output to search for event ID 644
6. Check through output to find the server/workstation performing lockout
If it isn't obvious when you log on to the offending machine what is causing the lockout, use the security event log on that system and search for failure events (id 529). Looking at these entries, you should be able to find the Caller Process ID, from which you can use Task Manager or Process Monitor from Sys Internals to track down the process concerned.
In my instance, it turned out to be a process called xf.exe, which in turns is the HP Management Infrastruture service, used for managing HP EVA's. I had a disconnected RDP session open to Command View, and it was this using the old credentials, which subsequently kept locking me out :(
Giving the session did the trick :)
1. From the extracted download, run LockoutStatus.exe
2. type in user to query
3. Check if account is locked. If it is, check Orig Lock column to determine DC that locked account
4. Connect to Security log of the DC in question
5. Filter output to search for event ID 644
6. Check through output to find the server/workstation performing lockout
If it isn't obvious when you log on to the offending machine what is causing the lockout, use the security event log on that system and search for failure events (id 529). Looking at these entries, you should be able to find the Caller Process ID, from which you can use Task Manager or Process Monitor from Sys Internals to track down the process concerned.
In my instance, it turned out to be a process called xf.exe, which in turns is the HP Management Infrastruture service, used for managing HP EVA's. I had a disconnected RDP session open to Command View, and it was this using the old credentials, which subsequently kept locking me out :(
Giving the session did the trick :)
SCOM 2007 R2 : Updated Documentation
The updated Managment Pack Authoring guide is now available for download from here
Subscribe to:
Posts (Atom)