/bundles/itninjaweb/img/Breadcrumb_cap_w.png

Blog Posts tagged with Supporting Windows

Ask a question

Custom Deployments

Custom Deployments is a new feature in version 6.0 of the KACE Systems Deployment Appliance (SDA) that allow users to deploy a set of tasks to a Windows workstation without deploying an image or scripted install. 

With a custom deployment, no hidden tasks are automatically assigned like in an image or scripted install.  This means that everything needing to run will have to be manually assigned and for this reason, it is considered an advanced feature.  The 6.0 release of the SDA includes 2 custom deployments by default; x86 and x64 variations of "Scan User States Offline and Shutdown".  This is a perfect example of a custom deployment because after the task is complete and the shutdown command is given, the deployment shows as completed.  In the past, you would need to do a batch script to shut down, and because the built in tasks did not run, it would never display as successfully completed and it would stay in the Progress portion of the UI until removed.  This is just one example of a custom deployment, there are other great ways to leverage them.

We are including these downloads to get you started, you must be a member of the K2000 community on ITNinja to gain access.  After extracting the download, the package can be imported into the SDA.  The import is a task group (another new feature of 6.0) that contains all the tasks needed for the custom deployment. Since each custom deployment is assigned a specific architecture, it is easier to provide them as a single package with task groups

To use the imported item, create a new custom deployment, apply the appropriate task group, and save.  All the tasks are named with [CU] as a prefix, as CU is the prefix used when exporting custom deployments. By implementing this naming scheme it is easy to find the tasks commonly used for custom deployments.  I also name my custom deployments with the [CU] prefix.

******NOTE
Do not import these tasks into any version less than 6.0, it will cause issues.

Windows 10 in-place upgrade.  This custom deployment is used when an in-place upgrade of Windows 10 is needed, either from Windows 7/8 or an earlier build of Windows 10.  The same edition must be used when upgrading.  The auto logon and prepare Windows 10 tasks need to be customized for your environment, make sure to read the notes.

Run tasks in an operating system.  If you have tasks that need to be run within the OS, then this task group is needed for everything to run the way you would expect. Some tasks need to be customized for your environment, make sure to read the notes.

USMT, DoD Wipe and Shutdown.  This task group will scan user states offline, partition/format the drive, perform a 7-pass DoD wipe and then shut the machine down.  We have referenced the SysInternals tool SDelete.  We cannot include the executables as we do not have rights to distribute them, but the task has a link to download SDelete from Microsoft.  Once you have downloaded SDelete, extract the file, download the SDelete.bat file from the task and then ZIP the 3 files together. Use the resulting ZIP file to replace the BAT file in the task.  The BAT file will determine which architecture is running and run the appropriate application.  No other changes are needed unless you want to change some of the SDelete parameters, those changes would need to be made in the BAT file before it is added to the ZIP.

How will you use custom deployments?  If you have any interesting ideas that you believe others can use, export your tasks as a task group, making sure to have the tasks named with [CU].  Please review the tasks that are included here first and try to reuse those so we can stay consistent. Email your exported task groups to Corey Serrins [corey dot serrins at quest dot com] and we will add those to this page.



View comments (2)

Step-by-step: How to create a network bootable floppy


A Step-by-Step: Creating a Network Boot Disk 

Using Windows NT's Network Client Administrator

Creating a network boot disk can be a real headache. The subject is documented fairly poorly and tools to help you do the job are equally hard to come by. Due to the need for network startup disks for use with imaging software, this has become a regularly revisited subject at AppDeploySM. Though most imaging software packages come with their own network boot disk generation utility, even with these you may still want to create your own in an attempt to get the most optimal use of the limited space you have on that floppy disk. Step-by-step instructions covering how to do it yourself seem to be very difficult to find- so here goes:

 Network Client Administrator Installation

Network Client Administrator Installation

If you have an NT workstation you may skip to "Network Client Administrator Execution". Windows 2000 does not include an equivalent tool, however you may use the Windows NT version of the tool on a Windows 2000 system by performing the following steps: 

Create a folder called C:\Ncadmin.

Create a subfolder called C:\Ncadmin\Clients

Copy the following files from the I386 folder on the Windows NT Server 4.0 CD-ROM to the folder you created:

  •  Ncadmin.cn_

  •  Ncadmin.ex_

  • Ncadmin.hl_

At a command prompt, change to the C:\Ncadmin folder, and then type the following command:

"expand -r ncadmin.*"

Double-click Ncadmin.exe to launch the utility.

 Network Client Administrator Execution

Network Client Administrator Execution

Note: If you know that your network card is not listed, you will need to implement the steps below to add it to those available before proceeding.

Once launched, select the “Make Network Installation Startup Disk” from the menu and press the “Continue” button to begin.

You are requested to provide a path to the client installation files. Enter “C:\Ncadmin\Clients” as the path if you followed the steps above (or the appropriate directory if running from an existing NT Server installation), select the “Share Files” radio button and press “OK”.  This will share the "C:\Ncadmin\Clients" folder as “clients”, which you may feel to remove after your network boot disk has been created. 

The next dialog prompts you to choose what type of floppy, network client, and network card driver you wish to create the boot disk for. Choose “Network Client v3.0 for MS-DOS and Windows” as your network client.  Select your network card from the list and press “OK” to continue. If your network card is not listed, see “Adding new entries to the Network Client Administrator” below.

The next dialog will prompt you for startup disk configuration information including Computer Name, User Name (must be unique on the network), Domain, and Protocol and (if necessary) IP information. Select “TCP/IP Protocol” from the protocol dropdown list, it may appear that there is only one item to select- look closely and you should see a very small scroll bar in the dropdown list (push the down arrow to see “TCP/IP Protocol”). If available it is recommended that you use DHCP for simplicities sake- otherwise fill in the proper IP information here. 

Next the boot disk itself will actually be created. You will need to provide a blank, formatted system disk (bootable) for the files to be placed on. Windows NT/2000 cannot do this for you, as there is no DOS equivalent operating system present to place on the floppy. Go to a DOS or Windows 9x machine and format the disk with the “/s” option to create the blank, formatted system disk. This should NOT be a Windows NT formatted diskette.

As the floppy is populated with the necessary files a progress dialog is presented. When complete, you have your network boot floppy. If you should run into problems see some tips at the end of this document, our network boot disk creation FAQ or visit our network boot disk user forum.

 Adding New Entries to the Network Client Administrator

Adding New Entries to the Network Client Administrator

1. Copy the “Clients” subdirectory from the Windows NT Server compact disc to “c:\Ncadmin\clients”. Note that this requires nearly 70 megabytes (MB) of disk space.

2. Copy the network card’s entry in the [netcard] section of your NDIS2 driver's Oemsetup.inf and paste it into the [netcard] section of the file Wcnet.inf, found in the "\Clients\Msclient\Netsetup" folder.

For example, the following is the [netcard] section of the 3com 3C90x driver's Oemsetup.inf file:

[netcard]

tcm$el90x="3Com EtherLink PCI NICs (3C90X)",0,ndis,ethernet,0x07,tcm$el90x,tcm$el90x_nif

3. Append the NDIS2 driver's header and NIF section from the Oemsetup.inf file to the bottom of the same Wcnet.inf file.

For example, the following are the header and NIF sections of the 3com 3C90x driver's Oemsetup.inf file:

[tcm$el90x]

ndis3=1:el90x.386
ndis2=1:el90x.dos
mlid=1:3c90x.com

[tcm$el90x_nif]

param=DriverName,"",static,"el90x$"
slot=SLOT,"Adapter Slot Number",int,"1,64,1",1,0x32
param=earlyrelease,"Early Release Option",keyonly,,,0x02
param=maxrequests,"Maximum number of general requests",int,"3,10,1",3,0x02
param=maxmulticasts,"Maximum number of multicast addresses",int,"1,50,1",16,0x02
param=maxtransmits,"Maximum number of queued transmits",int,"3,50,1",10,0x02
param=maxreceives,"Maximum Receive Buffers",int,"3,30,1",3,0x02
param=maxframesize,"Maximum frame size",int,"256,17952,8",4096,0x02

4. If in step three the data you appended contained DEVDIR= and/or DEVICE= entries, delete those lines from the file (Wcnet.inf).

5. If not already present, add the line, "ndis2=1:<drivername>" to the header (first part) of the data appended and save the Wcnet.inf file.  The driver name should have the .DOS extension. The 3com example above already contains this entry.

6. Copy the NDIS2 driver to the "\Clients\Msclient\Netsetup" folder.

In the 3com 3c90x example you would copy the file el90x.dos to the "\Clients\Msclient\Netsetup" folder.

 Troubleshooting Your New Network Boot Disk

Troubleshooting Your New Network Boot Disk

Error 33: Unable to Bind

Some cards require the Drivername value to be set under the header section in the Protocol.ini file. For example the 3c905 example described above exhibited this error until the protocol.ini file was edited to include the entry “drivername=el90x$” as follows:

[network.setup]

version=0x3110
netcard=tcm$el90x,1,TCM$EL90X,1
transport=tcpip,TCPIP
lana0=tcm$el90x,1,tcpip

[tcm$el90x]

DriverName=el90x$   <---- Note DriverName entry was added manually

[protman]

drivername=PROTMAN$
PRIORITY=MS$NDISHLP

[tcpip]

NBSessions=6
DefaultGateway0=
SubNetMask0=
IPAddress0=
DisableDHCP=0
DriverName=TCPIP$
BINDINGS=tcm$el90x
LANABASE=0  
 

One visitor reports that the DriverName entry was case sensitive, so be careful. (and thanks to Brian Fort for sharing!)

If the problem persists, this error can also sometimes be attributed to a problem with the internal name used in the protocol.ini. The internal driver name of the NIC driver is not what is expected. The driver name is normally the same as the filename of the driver with a $ appended to the end (i.e. FEM556N2.DOS would be FEM556N2$), but this isn't true for all drivers, check with your NIC vendor. 

Need some space? You can delete the file "a:\net\neth.msg" as it is not needed (121 kb)

Need a packet driver? Check out this resource: ftp://ftp.crynwr.com/drivers/00index.html 

 

 
Be the first to comment

[Konf 2011] 100% Windows 7 Deployment Automation

For those of you who were at the Konference, you may have seen my presentation on Windows 7 automation that uses several methods to achieve total automation for the end user experience. For those of you who missed it or who didn't attend the Konference, here is the presentation:

100% Windows 7 Deployment Automation

I will be adding code examples to this post soon, but I at least wanted to make the presentation available. I will also post a link to the video of my presentation if and when it becomes available on the DellKACE website.

For the following examples, much of the code is written in AutoIT. If you are unfamiliar with AutoIT, head over to www.autoitscript.com and download the free IDE and compiler. Also, I wrote an O'Reilly book back in 2007 that is available on Amazon for $7.99 that gives you a basic start with the language. Now, here is the example list. This will be growing.

View comments (1)

Installing windows 7 admin tools as a post install task

A few people have asked if there was a scripted way to deploy the win 7 deployment tools so I thought I would share it.

This link has all the info that you need.


http://technet.microsoft.com/en-us/library/ee449483(v=ws.10).aspx

basically install Windows6.1-KB958830-x86-RefreshPkg.MSU using /quiet /norestart

(as a post install)

Then have a batch file that runs to install the components that you want.

dism /online /get-features to display the features that you need installed (on a machine that is already setup).

An example of using group policy management console is
dism /online /enable-feature /featurename:RemoteServerAdministrationTools /featurename:RemoteServerAdministrationTools-Features /featurename:RemoteServerAdministrationTools-Features-GP

Refer to the URL for additional options.

Be the first to comment

KACE: K2000 Windows 7 32bit Deployment

Start to deploy Windows 7 systems with K2000.

One question to ask:

License keys, currently, we do not have any volume licnese for Windows 7,and been told by our supplier that there is no such product.

Will follow up the license key settings before we can start to push the new Win7 systems with KACE.

 

View comments (3)
Showing 1 - 5 of 397 results

Top Contributors

Talk About Imaging