Friday 23 April 2010

Please Fill in this form....

One of the great things about Powershell is how it can help you remove repetative tasks,
it can run "any" application and perform "any" task and if you put it into the Scheduled Tasks system, it can do it over and over.

If you give it a small amount of information in can also gather in a huge amount on its own, from any number of sources,
for example Active Directory, a .CSV file, an Excel document or a SQL Database to mention a few.

This script does just that, it asks for a servicetag, it takes the tag and looks inside a .CSV file
where it finds the username of the user that is the primary user for that computer.
It then looks in Active Directory with the help of the Get-ADUser command found in the
RSAT Active Directory Module and collects even more information.

It then takes all that it has learned and puts that information into a Word Document (in this case a .Docx file)
with the help of predefined bookmarks and finally it prints out the document to the default printer.

In this example the Word Document is a form the user fills out when the computer
has suffered some major breakdown and is in need of service,
the IT guy\girl scans the servicetag and a form is printed.
No more sloppy handwriting, gone are the days when people ask "what's todays date?"
or "My Username?? I've got a Username!?!"

Powershell to the rescue!

Download it here: http://bit.ly/bOSXuE

Monday 19 April 2010

New layout!

I've changed the layout since the previous one didn't have much space.
This might make previous posts seem weird ;)

-A

Script to alter Computername in a SCCM Task Sequence.

If you need to change the name of a computer based on a pre-configured variable, this should help you to accomplish the task.

Download script from SkyDrive

To use the script, simply run it from a SCCM Task Sequence (Run Command Line f.ex) with the following string:
Cscript "pathtoscript"\NewComputerName.vbs /N:%VariableName%

If you wish to query the user for input, I suggest using OSD++, if you run OSD++ with the following XML,
the user can input a computer name and the input is stored in a SCCM Task Sequence called NewComputerName.


To use this input with the script, run the script with this string:
Cscript "pathtoscript"\NewComputerName.vbs /N:%NewComputerName%

Side note:
You can actually set the OSDComputerName Variable right in OSD++,
the reason I'm not doing so will become clear in a later post that is under construction.
-Alex

Monday 21 December 2009

The blessing that is OSD++ (OSDPlusPlus)


If you're limited to MDT or you're having a hard time getting SCCM to accept information\variables prior to OS Deployment, OSD++ might be exactly what you need!

OSD++ can run from a Task Sequence after you've added it's source directory to a package, by including different XML files you can request information from the user and apply any changes to the registry or to the unattended file itself.

It can read from and to the registry as well as give you easy access to WMI information.

OSD++ offers a quick and easy way to get the computername or install software based on the spesific choices made by the user.
The users can either fill in a textbox, with or without Regular Expressions to control that the input is valid, or with listboxes.

The choices can be stored in a XML for future use, in the registry or in the unattended file the computer is about to use for OS Deployment.

All it really lacks is LDAP support though you can "cheat" your way to this by using Distributed Files Service and a "IF EXSIST" Batch script.

Try it by downloading it here (Documentation)
Read more at the OSD++ Blog


Graded: A-
Only needs a few more features to make it a Must-Have-Software for anyone without SCCM and most with.

Edit: New grade based on new experiences

Saturday 19 December 2009

Christmas Joy, Modena style!



It's been ages since I posted, but I come bearing good news!
While I was gone, Microsoft has released another RC of Modena, the soon to be essential tool in every Operating System Deploying SCCM Administrator out there.

So what's Modena?
Well in short it's an awesome extension of SCCM.
A better way to describe it is to say that it allows for administrators to design OS deployment, to add menus for optional application installations, exclude or require application installation, and much more based on a wide range of variables.

This will allow you and me to create a simple user interface for the end-user, allowing them to refresh or upgrade their OS to Windows 7 while ensuring that the hardware software gets installed and that the users apps and documents are present at first login.

What makes it really great is the ability to perform cancelations, with grace non-the-less!
Just check out the list of features for RC2 posted over at Technet

  • Enhanced Application support including Dependency, Exclusion, Locking, Filtering, and Topological Sorting
  • Application Discovery Pre-Flight
AppDiscovery runs as a pre-flight check in the OSD Setup Wizard and scans the local system for ConfigMgr software packages or MSI product IDs, and upon detection, marks them for re-install. AppDiscovery also honors any of the dependency and exclusion rules by ensuring that conflicting values do not break the wizard. AppDiscovery even supports deprecated software detection logic to allow “upgrades” to the latest version.
  • Powerful WMI Query Language (WQL) Support
Beyond application re-configuration, AppDiscovery also supports custom WMI query definitions to support almost end-less possibilities for administrators. Why support this functionality?
There are several scenarios where application delivery is dependent on hardware specific values, such as Manufacturer and Model Types.
Using WQL queries, an administrator can easily determine the Make & Model and set application delivery specifically for that model. In short, driver payload(s), OEM specific applications are deliverable only if the WQL query returns true otherwise the applications are not delivered.
  • Friendly, easy-to-understand, Results of OSD Imaging
  • Welcoming the Modena OSD Designer
The OSD Designer allows you, as an OSD administrator, to do the following:

  • Allows you to create new or update existing OSD Setup Wizard configuration files
  • Save configuration files locally or publish to the Modena Online Service
  • Enable or disable any OSD Setup Wizard pages
  • Enable or disable any page configuration fields (e.g. computer name, etc.)
  • Connect to Active Directory and setup Domains and Organizational Units in OSD Setup Wizard configuration files
  • Connect to System Center Configuration Site Servers and retrieve packages enabled for OSD
  • Attach x86 and x64 applications and configure dependencies, exclusions, and set application packages as required
  • Configure Application Discovery matching criteria for ConfigMgr packages and MSI product Ids
The OSD Designer is any OSD administrators 2nd favorite tool behind Configuration Manager console. It greatly simplifies your preparation for delivering operating system images using OSD.

  • Modena (Configuration for Wizard & AppDiscovery) Online Services
When new applications are released that update OSD apps, you have to manage this in the configuration for Application Discovery’s configuration to detect the updated version, package identification, or program name and do so a per-package level. This requires updates are done and then refreshed on all the DPs in your hierarchy with the package and this is cumbersome and prone to error.
  • Simplified Cancellation Functionality

The OSD task sequence and Wizard are now updated to support graceful cancellation. This improved functionality simplifies reporting and ensures the preferred user experience for end-users when they are not willing to continue the wizard. The difference between a failed task sequence (unknown root cause) is vastly different from an end-user who decides to cancel the wizard or doesn’t meet the requirements. This shuts the task sequence down gracefully and ensures to report the information accurately.
  • Quick and Easy Installation & Setup

Check out more here:




Friday 5 June 2009

KSOD - My lil fix.

Okay, so here are "more detailed" instructions on how I fixed the Black Screen Of Death (KSOD) problem.

Like I said, the error in our case came about because a Group Policy Object I made included security permissions for several services, among them the services:

  • Remote Procedure Call (RPC)
    And
  • Remote Procedure Call (RPC) Locator.
The default settings presented included the Administrator Group and the SYSTEM & INTERACTIVE accounts.
The account "NT AUTHORITY\NetworkService" was not included meaning that when the account later would try to read a setting (or do anything else) regarding the RpcSs service, it would fail and the resulting error made the Operating system reboot as defined in the recovery settings.

To solve this I PXE booted the computer into Windows PE available on our WDS Server and started RegEdit.
I incorrectly stated earlier that I didn't apply the change to the Hive but a review showed me that I had.
See this guide on how to load the %windir%/system32/config/SYSTEM hive and finding the HKEY_LOCAL_MACHINE\SYSTEM\Select\Current KEY.

This Key tells you what ControlSet Vista is currently using ("Current"), by Default and which ControlSet is "Last Known Good".
In my case the key for Current was 1, meaning HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RpcSs and the permissions applied to that container (or individual keys stored there) needed to be changed.

By right clicking on HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RpcSs and selecting "Permissions" I could grant NetworkService the READ right and before rebooting I made sure it was also applied with the help of inheritance.


Note: The first test was to grant the Account Full controll, which also worked but seems to be overkill.

  • Click on add
  • Click Advanced
  • Change Location to your Computer (if required)
  • Hit the find button and select the Network Service account.
  • Grant the account READ rights.
You might want to make sure the Enum and Parameters containers inherit the permissions as well.

After a Reboot, the Operating System should be able to boot as normal and the login window should show up after a short delay.

I hope this can help to shed some light on this problem for some of you, if it doesn't then feel free to drop me a line after checking out the other options presented below.
Last Revised:
17:47 - June 5th 2009