MDT

Reversal of fortune: Sirefef’s registry illusion

Microsoft Deployment Toolkit Team Blog - Mon, 08/19/2013 - 19:38

​I have mentioned in a previous blog that the use of the right-to-left-override (U+202E) unicode character is nothing new. This blog also went on to show the various file name tricks used by malware.

But now we see something different: the use of this trick by variants of the Sirefef family of malware. The variants use the right-to-left-override character in the registry in order to hide its presence by mimicking a setting instantiated by a Google Chrome installation.

When a user installs an enterprise version of Google Chrome the application sets the following entries in the registry for the Google update service.

The update service shows up in the list of services as follows:

Looking at the properties gives you the details of the service, including the location of the file and description.

In the case of Sirefef, the registry entry appears to be the same as the one for Chrome:

There appears to be two "gupdate" registry entries. The real Google update entry is marked in the image above. There are now two entries in the services list which are almost identical, including the description of the service:

The real service is marked in the image above. Looking at the properties of the Sirefef service, you can see the difference to the real service.

Of course the illusion breaks down if the Sirefef registry entry is viewed without Unicode support:

The image below is the Unicode string including the RLO character used by Sirefef:

This demonstrates yet another concerted attempt by malware to hide itself in plain sight by pretending to be something it is not. It may make it difficult for someone doing a cursory check to determine if they are infected. As always, make sure you have up-to-date antimalware software and install the latest Windows updates.  Raymond Roberts
MMPC        

 

Categories: MDT

Reversal of fortune: Sirefef’s registry illusion

The USMT team blog - Mon, 08/19/2013 - 19:38

​I have mentioned in a previous blog that the use of the right-to-left-override (U+202E) unicode character is nothing new. This blog also went on to show the various file name tricks used by malware.

But now we see something different: the use of this trick by variants of the Sirefef family of malware. The variants use the right-to-left-override character in the registry in order to hide its presence by mimicking a setting instantiated by a Google Chrome installation.

When a user installs an enterprise version of Google Chrome the application sets the following entries in the registry for the Google update service.

The update service shows up in the list of services as follows:

Looking at the properties gives you the details of the service, including the location of the file and description.

In the case of Sirefef, the registry entry appears to be the same as the one for Chrome:

There appears to be two "gupdate" registry entries. The real Google update entry is marked in the image above. There are now two entries in the services list which are almost identical, including the description of the service:

The real service is marked in the image above. Looking at the properties of the Sirefef service, you can see the difference to the real service.

Of course the illusion breaks down if the Sirefef registry entry is viewed without Unicode support:

The image below is the Unicode string including the RLO character used by Sirefef:

This demonstrates yet another concerted attempt by malware to hide itself in plain sight by pretending to be something it is not. It may make it difficult for someone doing a cursory check to determine if they are infected. As always, make sure you have up-to-date antimalware software and install the latest Windows updates.  Raymond Roberts
MMPC        

 

Categories: MDT

Reversal of fortune: Sirefef’s registry illusion

​I have mentioned in a previous blog that the use of the right-to-left-override (U+202E) unicode character is nothing new. This blog also went on to show the various file name tricks used by malware.

But now we see something different: the use of this trick by variants of the Sirefef family of malware. The variants use the right-to-left-override character in the registry in order to hide its presence by mimicking a setting instantiated by a Google Chrome installation.

When a user installs an enterprise version of Google Chrome the application sets the following entries in the registry for the Google update service.

The update service shows up in the list of services as follows:

Looking at the properties gives you the details of the service, including the location of the file and description.

In the case of Sirefef, the registry entry appears to be the same as the one for Chrome:

There appears to be two "gupdate" registry entries. The real Google update entry is marked in the image above. There are now two entries in the services list which are almost identical, including the description of the service:

The real service is marked in the image above. Looking at the properties of the Sirefef service, you can see the difference to the real service.

Of course the illusion breaks down if the Sirefef registry entry is viewed without Unicode support:

The image below is the Unicode string including the RLO character used by Sirefef:

This demonstrates yet another concerted attempt by malware to hide itself in plain sight by pretending to be something it is not. It may make it difficult for someone doing a cursory check to determine if they are infected. As always, make sure you have up-to-date antimalware software and install the latest Windows updates.  Raymond Roberts
MMPC        

 

Categories: MDT

Reversal of fortune: Sirefef’s registry illusion

The Deployment Guys - Mon, 08/19/2013 - 19:38

​I have mentioned in a previous blog that the use of the right-to-left-override (U+202E) unicode character is nothing new. This blog also went on to show the various file name tricks used by malware.

But now we see something different: the use of this trick by variants of the Sirefef family of malware. The variants use the right-to-left-override character in the registry in order to hide its presence by mimicking a setting instantiated by a Google Chrome installation.

When a user installs an enterprise version of Google Chrome the application sets the following entries in the registry for the Google update service.

The update service shows up in the list of services as follows:

Looking at the properties gives you the details of the service, including the location of the file and description.

In the case of Sirefef, the registry entry appears to be the same as the one for Chrome:

There appears to be two "gupdate" registry entries. The real Google update entry is marked in the image above. There are now two entries in the services list which are almost identical, including the description of the service:

The real service is marked in the image above. Looking at the properties of the Sirefef service, you can see the difference to the real service.

Of course the illusion breaks down if the Sirefef registry entry is viewed without Unicode support:

The image below is the Unicode string including the RLO character used by Sirefef:

This demonstrates yet another concerted attempt by malware to hide itself in plain sight by pretending to be something it is not. It may make it difficult for someone doing a cursory check to determine if they are infected. As always, make sure you have up-to-date antimalware software and install the latest Windows updates.  Raymond Roberts
MMPC        

 

Categories: MDT

Hyper-V WMI v2 Porting Guide

Virtual PC Guy's WebLog - Mon, 08/19/2013 - 17:13

I have been getting more and more questions about how to use the Hyper-V v2 WMI namespace recently – so I have just created a TechNet Wiki article that links to a number of samples / documentation pages about how to do this.  You can get all the details here:

http://social.technet.microsoft.com/wiki/contents/articles/19192.hyper-v-wmi-v2-porting-guide.aspx

Cheers,
Ben

Categories: MDT

Installing IE10 into your Windows 7 image? You’re missing an update or two…

cluberti.com - Mon, 08/19/2013 - 09:57

If you’re like me, you like to make sure the latest version of Internet Explorer supported by your organization is baked into the images you push into production, and IE10 on Windows 7 is no different.  Whether you’re slipstreaming it into the base image, or (better) using MDT to rebuild your base image and including IE10 into it, Microsoft has provided a handy list of updates that you should have already included before you attempt to install IE10 on Windows 7:
How to obtain prerequisite updates for Internet Explorer 10 for Windows 7 that fail to install

That article lists 4 hotfix packages you will need – KB2533623, KB2670838, KB2729094, KB2731771, and KB2786081.  However, the astute amongst you have probably noticed that the IE10 installer, when left to it’s own devices during install, actually installs 6 hotfix packages, not 5.  That “extra” hotfix package is:
“0×00000050″ Stop error after you install update 2670838 on a computer that is running Windows 7 SP1 or Windows Server 2008 R2 SP1

I don’t know that Microsoft will update their KB article to include the additional update (it isn’t a required package to install IE10, technically), but there you have it.  If you’re trying to match what IE10 does natively when it installs when integrating it into your own Windows 7 images (and you probably should), you will likely want to install that additional update as well as the required 5.

Categories: MDT

System Center 2012 R2 Available October 18th

Microsoft Deployment Toolkit Team Blog - Wed, 08/14/2013 - 09:00

In important news today, we are extremely excited that on October 18th, eligible customers will able to download Windows Server 2012 R2, System Center 2012 R2, and use the latest update to Windows Intune. This is the same day that Windows 8.1 will be available to consumers and businesses worldwide. Microsoft Vice President Brad Anderson details this exciting news in his latest blog, "Mark Your Calendars for October 18th, the R2 Wave is Coming".

Read the news and give these new products a try today! You can download the preview bits here, and learn more about all the new innovations in the R2 products by following Microsoft Vice President, Brad Anderson’s special blog series, “What’s New in 2012 R2”  now underway.

 Get more news on the R2 wave of products by following @System_Center and Brad Anderson @InTheCloudMSFT on Twitter!

Categories: MDT

System Center 2012 R2 Available October 18th

The USMT team blog - Wed, 08/14/2013 - 09:00

In important news today, we are extremely excited that on October 18th, eligible customers will able to download Windows Server 2012 R2, System Center 2012 R2, and use the latest update to Windows Intune. This is the same day that Windows 8.1 will be available to consumers and businesses worldwide. Microsoft Vice President Brad Anderson details this exciting news in his latest blog, "Mark Your Calendars for October 18th, the R2 Wave is Coming".

Read the news and give these new products a try today! You can download the preview bits here, and learn more about all the new innovations in the R2 products by following Microsoft Vice President, Brad Anderson’s special blog series, “What’s New in 2012 R2”  now underway.

 Get more news on the R2 wave of products by following @System_Center and Brad Anderson @InTheCloudMSFT on Twitter!

Categories: MDT

System Center 2012 R2 Available October 18th

In important news today, we are extremely excited that on October 18th, eligible customers will able to download Windows Server 2012 R2, System Center 2012 R2, and use the latest update to Windows Intune. This is the same day that Windows 8.1 will be available to consumers and businesses worldwide. Microsoft Vice President Brad Anderson details this exciting news in his latest blog, "Mark Your Calendars for October 18th, the R2 Wave is Coming".

Read the news and give these new products a try today! You can download the preview bits here, and learn more about all the new innovations in the R2 products by following Microsoft Vice President, Brad Anderson’s special blog series, “What’s New in 2012 R2”  now underway.

 Get more news on the R2 wave of products by following @System_Center and Brad Anderson @InTheCloudMSFT on Twitter!

Categories: MDT

System Center 2012 R2 Available October 18th

The Deployment Guys - Wed, 08/14/2013 - 09:00

In important news today, we are extremely excited that on October 18th, eligible customers will able to download Windows Server 2012 R2, System Center 2012 R2, and use the latest update to Windows Intune. This is the same day that Windows 8.1 will be available to consumers and businesses worldwide. Microsoft Vice President Brad Anderson details this exciting news in his latest blog, "Mark Your Calendars for October 18th, the R2 Wave is Coming".

Read the news and give these new products a try today! You can download the preview bits here, and learn more about all the new innovations in the R2 products by following Microsoft Vice President, Brad Anderson’s special blog series, “What’s New in 2012 R2”  now underway.

 Get more news on the R2 wave of products by following @System_Center and Brad Anderson @InTheCloudMSFT on Twitter!

Categories: MDT

The original AppCompat (solving a 20-year-old mystery for me)

Microsoft Deployment Toolkit Team Blog - Tue, 08/13/2013 - 02:19

DOS v5.0, released in 1991, introduced the concept of DOS loading "high".  That is, into the high memory area - that special 64kb area at the top of the first megabyte of memory.

As a result of this change, programs now loaded to a much lower address in memory than they did before.  This change also exposed a previously unknown bug that exists in the code produced by certain versions of the Exepack utility, or Link* with the "/EXEPACK" option.  The bug caused memory corruption, which usually resulted in the process hanging during start-up.   There were a number of workarounds that involved forcing an allocation of 64kb (e.g. using loadfix) to ensure that the program loaded above the 64kb block - the usual "black box" solution.   By that point, there were so many ExePacked files that "please update your software" was not an option.   What made me think to solve it now?  It's my nature - I can't leave a mystery unsolved, no matter how long it takes me.   These days DOS viruses are extinct, but DOS games live on with the help of DOSBox.   I was working on a patch for DOSBox in my spare time.  The program worked in DOSBox if loadfix was run first, but it worked in all cases in real DOS.  Ah, the mystery deepens.   What's more interesting is that I saw the issue only by luck. I needed EMM386.EXE to be running and providing access to the Upper Memory Block area; I needed to load my debugger into the Upper Memory Block area; I needed to be debugging a program that was so large that it would not fit into the Upper Memory Block area along with the debugger; and, of course, I needed that program to be packed by ExePack.   It wasn’t likely, but it happened.   So, on the left is the code as it would be found on disk.  On the right is the code that I saw on that day, 20 years ago, in my debugger (and shortly thereafter, I found two other variations).  

  Wow, quite different.  What happened there?
 
Well, DOS went and rewrote that unpacking code for me, on-the-fly, as the file was loaded into memory.   That's right - DOS went and “hot-patched” my code to avoid a bug.  No warning, and no explanation - at the time, I didn't have an Internet connection, but it seems likely that even if I had, it would never have occurred to me to search for an answer.  Or if I did, the answer would not have been documented anywhere yet, anyway.  As you can see, Windows 95 was not the first platform to implement an application compatibility layer.   The mystery is finally solved.  As for DOSBox, you just have to use loadfix, but now you know why.   (*) Specifically, Link 3.x where x is 51 or larger, all 4.x, and 5.x where x is 15 or smaller.   Peter Ferrie
MMPC
Categories: MDT

The original AppCompat (solving a 20-year-old mystery for me)

The USMT team blog - Tue, 08/13/2013 - 02:19

DOS v5.0, released in 1991, introduced the concept of DOS loading "high".  That is, into the high memory area - that special 64kb area at the top of the first megabyte of memory.

As a result of this change, programs now loaded to a much lower address in memory than they did before.  This change also exposed a previously unknown bug that exists in the code produced by certain versions of the Exepack utility, or Link* with the "/EXEPACK" option.  The bug caused memory corruption, which usually resulted in the process hanging during start-up.   There were a number of workarounds that involved forcing an allocation of 64kb (e.g. using loadfix) to ensure that the program loaded above the 64kb block - the usual "black box" solution.   By that point, there were so many ExePacked files that "please update your software" was not an option.   What made me think to solve it now?  It's my nature - I can't leave a mystery unsolved, no matter how long it takes me.   These days DOS viruses are extinct, but DOS games live on with the help of DOSBox.   I was working on a patch for DOSBox in my spare time.  The program worked in DOSBox if loadfix was run first, but it worked in all cases in real DOS.  Ah, the mystery deepens.   What's more interesting is that I saw the issue only by luck. I needed EMM386.EXE to be running and providing access to the Upper Memory Block area; I needed to load my debugger into the Upper Memory Block area; I needed to be debugging a program that was so large that it would not fit into the Upper Memory Block area along with the debugger; and, of course, I needed that program to be packed by ExePack.   It wasn’t likely, but it happened.   So, on the left is the code as it would be found on disk.  On the right is the code that I saw on that day, 20 years ago, in my debugger (and shortly thereafter, I found two other variations).  

  Wow, quite different.  What happened there?
 
Well, DOS went and rewrote that unpacking code for me, on-the-fly, as the file was loaded into memory.   That's right - DOS went and “hot-patched” my code to avoid a bug.  No warning, and no explanation - at the time, I didn't have an Internet connection, but it seems likely that even if I had, it would never have occurred to me to search for an answer.  Or if I did, the answer would not have been documented anywhere yet, anyway.  As you can see, Windows 95 was not the first platform to implement an application compatibility layer.   The mystery is finally solved.  As for DOSBox, you just have to use loadfix, but now you know why.   (*) Specifically, Link 3.x where x is 51 or larger, all 4.x, and 5.x where x is 15 or smaller.   Peter Ferrie
MMPC
Categories: MDT

The original AppCompat (solving a 20-year-old mystery for me)

DOS v5.0, released in 1991, introduced the concept of DOS loading "high".  That is, into the high memory area - that special 64kb area at the top of the first megabyte of memory.

As a result of this change, programs now loaded to a much lower address in memory than they did before.  This change also exposed a previously unknown bug that exists in the code produced by certain versions of the Exepack utility, or Link* with the "/EXEPACK" option.  The bug caused memory corruption, which usually resulted in the process hanging during start-up.   There were a number of workarounds that involved forcing an allocation of 64kb (e.g. using loadfix) to ensure that the program loaded above the 64kb block - the usual "black box" solution.   By that point, there were so many ExePacked files that "please update your software" was not an option.   What made me think to solve it now?  It's my nature - I can't leave a mystery unsolved, no matter how long it takes me.   These days DOS viruses are extinct, but DOS games live on with the help of DOSBox.   I was working on a patch for DOSBox in my spare time.  The program worked in DOSBox if loadfix was run first, but it worked in all cases in real DOS.  Ah, the mystery deepens.   What's more interesting is that I saw the issue only by luck. I needed EMM386.EXE to be running and providing access to the Upper Memory Block area; I needed to load my debugger into the Upper Memory Block area; I needed to be debugging a program that was so large that it would not fit into the Upper Memory Block area along with the debugger; and, of course, I needed that program to be packed by ExePack.   It wasn’t likely, but it happened.   So, on the left is the code as it would be found on disk.  On the right is the code that I saw on that day, 20 years ago, in my debugger (and shortly thereafter, I found two other variations).  

  Wow, quite different.  What happened there?
 
Well, DOS went and rewrote that unpacking code for me, on-the-fly, as the file was loaded into memory.   That's right - DOS went and “hot-patched” my code to avoid a bug.  No warning, and no explanation - at the time, I didn't have an Internet connection, but it seems likely that even if I had, it would never have occurred to me to search for an answer.  Or if I did, the answer would not have been documented anywhere yet, anyway.  As you can see, Windows 95 was not the first platform to implement an application compatibility layer.   The mystery is finally solved.  As for DOSBox, you just have to use loadfix, but now you know why.   (*) Specifically, Link 3.x where x is 51 or larger, all 4.x, and 5.x where x is 15 or smaller.   Peter Ferrie
MMPC
Categories: MDT

The original AppCompat (solving a 20-year-old mystery for me)

The Deployment Guys - Tue, 08/13/2013 - 02:19

DOS v5.0, released in 1991, introduced the concept of DOS loading "high".  That is, into the high memory area - that special 64kb area at the top of the first megabyte of memory.

As a result of this change, programs now loaded to a much lower address in memory than they did before.  This change also exposed a previously unknown bug that exists in the code produced by certain versions of the Exepack utility, or Link* with the "/EXEPACK" option.  The bug caused memory corruption, which usually resulted in the process hanging during start-up.   There were a number of workarounds that involved forcing an allocation of 64kb (e.g. using loadfix) to ensure that the program loaded above the 64kb block - the usual "black box" solution.   By that point, there were so many ExePacked files that "please update your software" was not an option.   What made me think to solve it now?  It's my nature - I can't leave a mystery unsolved, no matter how long it takes me.   These days DOS viruses are extinct, but DOS games live on with the help of DOSBox.   I was working on a patch for DOSBox in my spare time.  The program worked in DOSBox if loadfix was run first, but it worked in all cases in real DOS.  Ah, the mystery deepens.   What's more interesting is that I saw the issue only by luck. I needed EMM386.EXE to be running and providing access to the Upper Memory Block area; I needed to load my debugger into the Upper Memory Block area; I needed to be debugging a program that was so large that it would not fit into the Upper Memory Block area along with the debugger; and, of course, I needed that program to be packed by ExePack.   It wasn’t likely, but it happened.   So, on the left is the code as it would be found on disk.  On the right is the code that I saw on that day, 20 years ago, in my debugger (and shortly thereafter, I found two other variations).  

  Wow, quite different.  What happened there?
 
Well, DOS went and rewrote that unpacking code for me, on-the-fly, as the file was loaded into memory.   That's right - DOS went and “hot-patched” my code to avoid a bug.  No warning, and no explanation - at the time, I didn't have an Internet connection, but it seems likely that even if I had, it would never have occurred to me to search for an answer.  Or if I did, the answer would not have been documented anywhere yet, anyway.  As you can see, Windows 95 was not the first platform to implement an application compatibility layer.   The mystery is finally solved.  As for DOSBox, you just have to use loadfix, but now you know why.   (*) Specifically, Link 3.x where x is 51 or larger, all 4.x, and 5.x where x is 15 or smaller.   Peter Ferrie
MMPC
Categories: MDT

Remapping Variables in MDT Database Queries

The Deployment Guys - Mon, 08/12/2013 - 21:37

There are occasions where the variables I needed to use to query or retrieve data from the database were not the ones that match the field names in the database.  Luckily, the MDT Gather process supports variable remapping in the database sections of CustomSetting.ini to do just that.

I demonstrated one type of variable remapping in my post on Model Aliases.  I wanted to query Model settings, apps, etc. using the ModelAlias instead of the Model.  Since Model is the field in the database that the queries use to find the records, we have to tell Gather that is should use the value found in the ModelAlias variable to query the Model field in the database instead.

The standard Make/Model Settings database section looks like the one below.  The table (view) in the database is MakeModelSettings and the fields used to find the records are Make and Model.

[MMSettings]
SQLServer=%MDTSQLServer%
Database=%MDTDatabase%
Netlib=%MDTNetlib%
SQLShare=%MDTSQLShare%
Table=MakeModelSettings
Parameters=Make, Model

For my ModelAlias Settings sections I only was interested in finding records with a matching Model field, but the value I wanted to match was actually stored in the ModelAlias variable.  The changes shown in red tell Gather to do exactly that:

[MASettings]
SQLServer=%MDTSQLServer%
Database=%MDTDatabase%
Netlib=%MDTNetlib%
SQLShare=%MDTSQLShare%
Table=MakeModelSettings
Parameters=ModelAlias
ModelAlias=Model

This tells Gather to use ModelAlias for the value of the input parameter and that this parameter is to match the Model field.

I recently needed to do the second type of variable remapping, placing the results from a field in a returned records into a variable that is different from the name of the field.  In my scenario, I needed to place the results of the different application queries into different list variables.  The default database sections for getting applications (CApps, LApps, MMApps, RApps) will fill the results into the Applications list variable, which matches the name of the field in the returned results.  I needed each of the queries to return the results into different variables so that I could later append them back together in a certain order with results from some other steps in the task sequence in the mix.  For example, say I wanted the store the results of MMApps into variable called ModelApps instead of applications.

The standard MMApps sections looks like this:

[MMApps]
SQLServer=%MDTSQLServer%
Database=%MDTDatabase%
Netlib=%MDTNetlib%
SQLShare=%MDTSQLShare%
Table=MakeModelApplications
Parameters=Make, Model
Order=Sequence

To return the results into ModelApps, you first need to define the custom variable in the Properties line and then add the remapping line to the MMApps section (shown in red).  (In case you haven’t see this, adding (*) at the end of a variable name in the Properties line tells Gather that the custom variable is a list variable.)

[Settings]
Priority=MMApps, Default
Properties=ModelApps(*)

[MMApps]
SQLServer=%MDTSQLServer%
Database=%MDTDatabase%
Netlib=%MDTNetlib%
SQLShare=%MDTSQLShare%
Table=MakeModelApplications
Parameters=Make, Model
Order=Sequence
ModelApps=Applications

One unfortunate quirk of this type of remapping is that the original variable (Applications) will also be filled with the results.  So you have to be aware of this if you had hoped that Applications would remain empty so it could be used else ware, as I had .  I was going to use Applications as the final appended list.  I had to use another custom list variable instead.

If necessary, you can also use both types of remapping in database sections at the same time.

Update 2013-08-20:  I forgot to mention that this same remapping of input parameters and output variables can also be done in CustomSetting.ini Web Service query sections.

Update 2013-09-10:  I recently discovered that when remapping input parameters, if the parameter is a list item then the remapped value will be added to the original list item.  For example, recently I wanted to query a list of applications from a specific role name and map it to a specific output list item like this:

[Settings]
Priority=Common, RAppsCore
Properties=RoleCore, CoreApps(*)

[Common]
RoleCore=Core Applications
MDTSQLServer=SQLServer001
MDTDatabase=MDT
MDTNetlib=DBNMPNTW
MDTSQLShare=SQLShare$

[RAppsCore]
SQLServer=%MDTSQLServer%
Database=%MDTDatabase%
Netlib=%MDTNetlib%
SQLShare=%MDTSQLShare%
Table=RoleApplications
Parameters=RoleCore
Order=Sequence
RoleCore=Role
CoreApps=Applications

In this example, RoleCore is being input for the parameter Role.  Since Role is a list item, the value stored in RoleCore, “Core Applications” in this example, will be added as Role001.  This is another thing to keep in mind when remapping variables.

I’ll describe ways to clear out the list items that are getting filled unintentionally by remapping in another post.

 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

Categories: MDT

Remapping Variables in MDT Database Queries

The Deployment Guys - Mon, 08/12/2013 - 21:37

There are occasions where the variables I needed to use to query or retrieve data from the database were not the ones that match the field names in the database.  Luckily, the MDT Gather process supports variable remapping in the database sections of CustomsSetting.ini to do just that.

I demonstrated one type of variable remapping in my post on Model Aliases.  I wanted to query Model settings, apps, etc. using the ModelAlias instead of the Model.  Since Model is the field in the database that the queries use to find the records, we have to tell Gather that is should use the value found in the ModelAlias variable to query the Model field in the database instead.

The standard Make/Model Settings database section looks like the one below.  The table (view) in the database is MakeModelSettings and the fields used to find the records are Make and Model.

[MMSettings]
SQLServer=%MDTSQLServer%
Database=%MDTDatabase%
Netlib=%MDTNetlib%
SQLShare=%MDTSQLShare%
Table=MakeModelSettings
Parameters=Make, Model

For my ModelAlias Settings sections I only was interested in finding records with a matching Model field, but the value I wanted to match was actually stored in the ModelAlias variable.  The changes shown in red tell Gather to do exactly that:

[MASettings]
SQLServer=%MDTSQLServer%
Database=%MDTDatabase%
Netlib=%MDTNetlib%
SQLShare=%MDTSQLShare%
Table=MakeModelSettings
Parameters=ModelAlias
ModelAlias=Model

This tells Gather to use ModelAlias for the value of the input parameter and that this parameter is to match the Model field.

I recently needed to do the second type of variable remapping, placing the results from a field in a returned records into a variable that is different from the name of the field.  In my scenario, I needed to place the results of the different application queries into different list variables.  The default database sections for getting applications (CApps, LApps, MMApps, RApps) will fill the results into the Applications list variable, which matches the name of the field in the returned results.  I needed each of the queries to return the results into different variables so that I could later append them back together in a certain order with results from some other steps in the task sequence in the mix.  For example, say I wanted the store the results of MMApps into variable called ModelApps instead of applications.

The standard MMApps sections looks like this:

[MMApps]
SQLServer=%MDTSQLServer%
Database=%MDTDatabase%
Netlib=%MDTNetlib%
SQLShare=%MDTSQLShare%
Table=MakeModelApplications
Parameters=Make, Model
Order=Sequence

To return the results into ModelApps, you first need to define the custom variable in the Properties line and then add the remapping line to the MMApps section (shown in red).  (In case you haven’t see this, adding (*) at the end of a variable name in the Properties line tells Gather that the custom variable is a list variable.)

[Settings]
Priority=MMApps, Default
Properties=ModelApps(*)

[MMApps]
SQLServer=%MDTSQLServer%
Database=%MDTDatabase%
Netlib=%MDTNetlib%
SQLShare=%MDTSQLShare%
Table=MakeModelApplications
Parameters=Make, Model
Order=Sequence
ModelApps=Applications

One unfortunate quirk of this type of remapping is that the original variable (Applications) will also be filled with the results.  So you have to be aware of this if you had hoped that Applications would remain empty so it could be used else ware, as I had .  I was going to use Applications as the final appended list.  I had to use another custom list variable instead.

If necessary, you can also use both types of remapping in database sections at the same time.

Categories: MDT

TFS queue build from powershell

NINet.org - Mon, 08/12/2013 - 08:22
I was doing some testing on TFS and got fed up queuing new builds via right-click -> queue new build -> ok. So here is a powershell script that can be used to kick off a build. I’ve included some extra assemblies that don’t need to be used as I have other functions that do [...]
Categories: MDT

Standalone Windows Intune – Managing Systems

Steve Rachui's Manageability blog - Sat, 08/10/2013 - 23:45
My last blog post provided details on how to setup and configure standalone Windows Intune in a test lab environment along with a walk through of the Windows Intune consoles and capabilities. This post will expand on options presented in the previous...(read more)
Categories: MDT

SommarKollo 2013 – MSAB

The Deployment Bunny - Thu, 08/08/2013 - 12:18

Här är mina sessioner (dom gula är mina sessioner)


Categories: MDT

Windows Server 2012 R2 Hyper-V – Hands On LAB

The Deployment Bunny - Thu, 08/08/2013 - 11:24

(In Swedish)

Har under våren och sommaren jobbat mycket med Windows Server 2012 R2 och väldigt mycket med Hyper-V vNext och därför ska det bli så förbaskat kul att köra första Hands-On LAB med fokus på Hyper-V baserat på Windows Server 2012 R2, principen är den samma som vi kört tidigare, du bygger en Hyper-V lösning under 3 dagar med i princip alla funktioner som finns, det blir en del UI saker, men framförallt blir det mycket PowerShell då det är det enda sättet att bygga Hyper-V lösningar numera. Då du har tillgång till mer än en server så bygger vi också upp kluster på rätt sätt. Vi snackar LAB på riktigt helt enkelt. Det är inte alltid som det blir fullt, men troligen så vill du vara först med R2 så får du boka upp dej på

http://labcenter.se/Labs#!lab=Mastering_Windows_Server_2012_Hyper_V

(English)

If you are English speaking and you would like to attend to a training on Windows Server 2012 R2 Hyper-V, check out http://www.truesec.com or send an email to per.kimblad@truesec.com

/mike


Categories: MDT

Pages