Basically, I am looking to have SCCM, during OSD deployment, copy a spreadsheet file that is located on our network to another location on our network but rename with a variable that the user will type before the OSD task starts.

So for those of you that PXE boot to drop an OS on the machine, you may have seen a variable for OSDComputername. This variable will allow us to put in the host name of the machine and after the OS is installed, it will update the host name on the machine so you don't have to do it later. I have been able to successfully do this with the AD Location and Description via the above link as well as have it drop the machine in a specific OU based on certain wording that I used to do this.

Now I need to add another variable that does the following. The user will enter in a series of numbers under a attribute I created called TICKETNUMBER. so lets say the ticket number is 123456. I enter this into the field I created right below OSDComputername. It starts the process of copying the OS to the machine, installs the drivers and all the typical things that OSD deployment does. Then it changes the host name (via OSDComputername) and when it gets to my created TS..which is just a VB script that says to copy the file that is in one network location and save it to another using the numbers I put in earlier. So it would change the name to 123456.xlsx and put it in a folder I specified (not on the local machine).

What I need to figure out is how to pull that data and have the VBS do this.. I also need to figure out how to add it in SCCM correctly.

I thought this would be simple. I added the attribute so that I can enter in these numbers prior to OSD deployment but I don't know how to get it to all come together... Anyone have any ideas on how to make this work? I am willing to give more info as needed.

It is fairly straight-forward but I need to ask a few questions as well.
First, are you familiar with MDT and the many variables it adds to OSD?
Have you installed and integrated MDT?

TS Variables

There are 3 types of variables you can use with ConfigMgr: in-built read-only, in-built dynamic and custom. If you are familiar with MDT there's a good description of them in the Help file.

e.g. OSDComputername is a dynamic variable. You can change the value but not the name.

You can create custom variables at two levels: collection or machine.
You can set the variables in 3 places: customsettings.ini, the TS or a script called from the TS.

For simplicity I would install and integrate MDT 2013 Update 2. The reason is that it gives you a key variable %deployroot%. This is read-only and points to the scripts folder of MDT, but the great thing is you can add a *new* folder below and then the pathing becomes easy:
%deployroot%\CompanyX\yourscript.vbs

Set the custom variable TICKETNUMBER on your OSD collection. If you're using unknown computers that's a good place to set it.
You also have two options: you can NOT set the value and when you PXE boot it will prompt, albeit with an ugly GUI. If you set it, you won't be prompted. You can however change it later any way you like: script, HTA script, TS.

Finally, you copy script will need to read the value of TICKETNUMBER. To do that, you just need to bind to the ConfigMgr environment. This is only active during OSD so a bit tricky to test. People typically use this to create build tattoos in the registry so that's an example of code you can use. The key line is:

See Peter's script for a tattoo example, but your ticket copy will very similar.

Finally, you can also use TS logic that branches depending on the TICKETNUMBER value without passing arguments to the script! Create a TS step Group, then click options and click Add "If any". Then click Add again and choose variable. Now type TICKETNUMBER as the name and a value.
Add a step inside the group to copy the file (without needing any argument to be passed). Rinse and repeat.

Unfortunately, we do not yet use MDT here. On the other hand, I tried to understand your response as best as I can. I have had some bit of success with everything except for the main objective.

So I have modified my script to copy a file from one network location to another network location but changing the name of the file to a name that I can put in prior to OS deployment. I added the collection variable: TICKETNUMBER and set it to All Unknown Computers. This is the variable that I want it to change the name to. So if I put 123456 as the value, when the TS runs, it will copy file WHATEVER.XLS to another folder and rename it 123456.XLS. I have all of the logic that I believe I need.

I created a package for the VBS and added it as the last step of the OS deployment. Everything works as it should except for the obvious step that I wanted. It will copy the file over but it does not pass the value over so instead of getting "123456.XLS", I just get ".XLS" (no name).

I wasn't sure if I needed to create a device collection but I am pretty sure I don't. I also have a feeling that I am not using the right code to pass the value. Does this make sense?

The logic is the same. I think you've done that, but the link is good to check against.

If you're getting .XLS then the variable's value is null. If you don't give a value up front, and it does NOT prompt then it will indeed be null. If you see the ugly two line GUI popup, then that's correct.

To check the variable during the TS you can add a step using "Run command line"
and then pipe it out to a file.

Your script looks fine, so it's just a matter of sorting why the TICKETNUMBER is not set.
Note, you could try moving the task up a bit so it's not the very last time, just to check that has no effect.
Variables are set after any "Gather" step, so don't put your test step before them, put it after.

If the file.txt doesn't help then we need to look at your smsts.log (or post it anyway). You can also add a step to explicitly set the variable with "Set TS variable" for testing.

What logic do you want though, and by that I mean how many different spreadsheet names do you need?

Mike
PS: Another good example of using variables is by Benoit Lecours, here:

You've done everything right, and the step is running with return code 0 (and getting the value as you said) but the problem you are hitting is permissions. Specifically, the log errors with:

failed to get the linked token information. It may not be available. Error 1312

which means ERROR_NO_SUCH_LOGON_SESSION or “A specified logon session does not exist. It may already have been terminated.” which points to a conflict between the context the step is running and the account.

In general, as the TS runs in system context you *cannot* access network shares etc. which is why they provide the "Run as" option. If the OS is W7x64, disable 64-bit redirection (check box).

I don't have a fix, as such but the options I would try are:

switch the script to PowerShell
use a different account (to test)
change the permissions on the share where the XLS lives to include SYSTEM

not necessarily in that order! Testing is tricky because if you run is as admin, I'm guessing it works perfectly. To test running as system people tend to use psexec (from sysinternals).

So I tried a different account as well as changing the copy location and destination just to see if there is an issue there. The file coies over from the ccmcache to the root of C: but still doesn't pass the value. I am stuck at this point. Not sure what to do. I am still trying to figure out how to create this in PS.

Software Metering within our group of companies has always been an afterthought until auditing of software and licensing became a pain point. Orchestrator and SCCM metering gave us the answer and it was an exciting process.

Visualize your data even better in Access queries. Given a date and a value, this lesson shows how to compare that value with the previous value, calculate the difference, and display a circle if the value is the same, an up triangle if it increased…

In response to a need for security and privacy, and to continue fostering an environment members can turn to for support, solutions, and education, Experts Exchange has created anonymous question capabilities. This new feature is available to our Pr…