h4x0r

AppEnforce.log shows "exit code 16389" when attempting to install the .NET 4.5 application I have as part of an OSD; however, if I deploy the application directly to a collection with the device, then it will install without any issue. The app also has the "allow this application to be installed from the Install Application..." option checked. Appenforce is also showing that it is correctly installing under the system context, so I don't believe it is a user context issue. Has anyone else run into a scenario like this? What are some additional clues I should be looking for?

Collecting information and seeing what others out there do when it comes to upgrading their server OS. This mainly came about through a discussion with a co-worker as we were retiring some Server 2003 boxes...what do you do when a wipe and fresh install is not an option? It may seem like an elementary question, but to me that would be the ideal process (wipe+fresh install), but it would seem that there are circumstances that don't make that a viable option, such as servers hosting various applications. I would think that if the function of the server is nothing more than, say, a file server, that upgrading would not be an issue (assuming that wiping the server is still not an option)...but I wanted some more input from the community to see what methods others are using.

Well I have met with decent success over the weekend...my process thus far has turned the whole printer deployment and setting the default printer (which has been the primary focus) into a two part deployment, rather than just one. While I was "close" with some of my prior ideas, having everything run as a single deployment element was causing problems...so I split it up where I was having trouble: part one is the actual printer installs, and part two sets the default printer. I modified my PS script so that in the first part, rather than actually set the default printer, I instead created a couple registry values that the second part of the deployment would use to set the default printer. Then, in the second part, I set a required deployment that also ran the first part of the install script (based on the presence of said registry value), and then taking the other registry value (the name of the default printer) proceeds to set the defaullt printer. This required deployment was set to run only while a user is logged in...so once their workstation is imaged and they logon for the first time, it will run and set the default printer from what has already been installed during OSD (if need be). I still have more testing to do to verify that everything works under different circumstances, but so far, the fact that the default printer is getting set at this stage is still moderate success in my book. If anyone would like exact details on how I have this setup, I will hapily provide those.

So far my testing and searches haven't turned anything up...I think I'm going to look at registry modification though. There are a couple settings which modifying doesn't require a restart, and may have the desired effect. but that could also have some very unpredictable results.

I saw that post, but installing the printers isn't the issue (installing the printers has been the only part of this which is working as it should right now)...the problem comes when trying to set the default printer. If I can set the default printer after the install, the setting seems to stick for other users who logon afterwards...but as of right now, I can't find a method to set the default printer through a TS

No dice there...creating a program to run under the user context is unusable in a TS...back to the drawing board...

Ok, one more step closer to getting this straightened out. If i add a run command line step (rundll32 printui...) to set the default printer in my TS and in the options set it to run as myself--which is the current logged in user--then it will work. However, it has issues if I use a service account, and I suspect that it is because the user is not logged in/the profile is not loaded to make the change. I'm going to create a package with the rundll32 printui... command as a program, and set it to run under the current logged in user and see if that has any success.

Well we have a winner...system context will not set the default printer...which makes sense, I guess, being as that is typically a per-user setting. Headed back to google now, but I'll go ahead and ask here as well... So how would I run a script in a TS under the user context?

Well we have a winner...system context will not set the default printer...which makes sense, I guess, being as that is typically a per-user setting. Headed back to google now, but I'll go ahead and ask here as well... So how would I run a script in a TS under the user context?

Thanks for the response, Peter...I feel rather like an idiot, because I should have tested that already. I will do that today and report back what I find.

One of the things we have implemented with our in-place refresh is re-installing printers with a powershell script...yes, I know there are ways to do this with GPO...I'm not going into the details, but suffice to say that GPO printer installs are not an option right now (unfortunately). But here's what I have run into...in my powershell, I'm executing the rundll32 printui.dll command. The script loops through and collects info on the printers which were installed and then choses the appropriate printer from that list to set as default, again using the rundll32 printui command. I have to use the rundll32 method because the prnmngr.vbs requires elevation to install a printer, which I can't get through a TS (at least not easily). If I simply run the script by itself then things work perfectly...all printers install and the default is set at the end. However, when running it from a TS, the only thing which doesn't work is setting the default printer. Since it wasn't working in my PS TS step, I figured I would hard-code it in with a Run Command Line step, passing a TS variable in my PS code. That didn't work either. I even setup a VBScript to set the default printer, but that did not work. I'm out of ideas at this point, and I don't know why it wouldn't be working from a TS other than it might be because it is running under a system context instead of a user? I don't know...I'm just stumped right now, and I'm too close to the project right now to think outside of the box at the moment. Any input would be appreciated. thanks.

You might check this out...User Driven Installation http://www.windows-noob.com/forums/index.php?/topic/10252-prompt-to-select-which-application-to-install-osd-process/?p=38576 See Anyweb's response with the links

Yes, but this can get very tricky if you're letting the end user refresh their Win7/8. Firstly, you have to make an available deployment that targets a certain group of computers (don't want to advertise an OSD to All Computers). Secondly, what sort of security do you have on your PXE point? Is it password protected? Are you going to give that password out? Will you have something that handles the frontend pieces such as a media hook HTA that requires user authentication? Point being in this case, is that you don't want someone accidentally imaging their workstation.

So not that I want to do this specifically, but the question was posed to me today at work as a means of alleviating bandwidth while imaging at some of our school locations. Does a DP require that it have a static IP address? Otherwise, in theory the workstation it was being hosted on could move from location to location, acting as a sort of "mobile" DP. Firstly though, I'm not sure how client -> server communication works during the imaging process and when selecting an available DP...my understanding was that the client would report to MP, and MP would tell it where the "nearest" DP for content would be. If the DP is discovered/resolved via standard DNS, then I could see how not giving the workstatio a static IP would allow it to move around between subnets where needed, when/if needed. The only reason this came up is because we're looking at re-imaging an entire location, and would like to keep that traffic on their LAN rather than coming back across our fiber to the main core. Again, this is all theoretical...but I was just wondering if anyone had actually done this before. Thanks for any input!

I had no errors or warnings pop up during the check that runs for the installer, but had a some come up during the actual installation. I Currently have green check marks next to all the list items on the installation status screen, and the "Overall progress" bar is completely full, but the Previous, Next, and Cancel buttons are still greyed out. Last entry in the log file was "INFO: SQL Connection succeeded. Connection: SMS_ACCESS, Type: Secure", but that was obviously several hours ago at this point. I believe that some of the errors I had earlier were because I was logged on with a different account (my own admin account) than what everything was installled with initially. This was moving from a 2012 SP1 install, and yes, I did remove the ADK 8.0 and installed 8.1 beforehand. Any advice here? [edit] As a side note, I was looking through Anyweb's R2 upgrade guide and noticed that there should be far more component entries listed near the end of the install...my last list item is "Monitoring replication initialization"...based on the screenshot Anyweb provided, I should have a scrollable list there by the end.

Hello everyone, I've been digging through posts both here and over at the technet site...what I'm trying to come up with is a collection for devices which have a primary user set for them. I've tried a number of different queries from various posts, but each time they don't return any results. I'll openly admit that I'm pretty worthless when it comes to query building, but I can at least say that the queries I was trying out did not have any errors in them. The other thing that I'm seeing is that in some circumstances, Service Manager was installed in the environment as well. We presently don't have that setup here...is that a requirement for some of these queries? I'm hoping not... I honestly hope that there's someone out there who actually has something like this in place that can help me get it sqared away. Thanks!

So like many people a while back, we ran into the issue of older workstations not PXE booting after upgrading to SP1. At the time, I remembered seeing somewhere that someone had made a collection to show which workstations were either capable or incapable of running Windows 8...however, I am unable to track this down. I've got meetings for the rest of the morning, so I can't just jump in right now and start experimenting...but I was curious if anyone else had similar collections setup for Windows 8 compatibility, and if they would mind sharing the query that they used?

Well I feel kinda stupid...I rebuilt my TS, and apparently must have had something not set right, because our fresh image will install correctly now without the Apply Data Image step. I just tell the Apply OS Image step to apply image 2-2 to the next available formatted partition and it is working with my hardlink now.

So back when we updated CM2012 to SP1, I noticed that after we updated our freshly captured images, that suddenly the deployment was failing on them. The only thing I found (at the time) to fix the issue was to include the Apply Data Image step in the TS, which applied image 1-1 to a 100MB partition that was created earlier in the format and partition step. Then I would apply image 2-2 (which is the OS) to the other partition (which would be the system drive). The long and short of it is this: when using the USMT with hardlinks, the format and partition step is skipped, and when the TS gets to the Apply Data Image step, it fails because the 100MB partition is not formatted and ready for data. I'm concerned that it will fail anyway if I leave it out (as was the case after updating to SP1), but it is failing now, so I'm none the worse for it. I didn't mind having to add the Apply Data Image step back a couple months ago, but I did find it odd that we had gotten along fine without it until then. Is there something I'm missing regarding the format and partition step, as well as the Apply OS Image step that is making it more complicated? It seems that other TS examples that I've looked at recently do not always have the Apply Data Image step, which makes me more curious now. If I can do without it, then it would seem to resolve my USMT hardlink issue...but right now, my standard TS will not complete without it anyway, so it make me wonder if there's something odd that I'm forgetting to do when capturing/applying the OS image. Any help is greatly appreciated!

Thanks for the info, binarymime. While we've been using CM2012 for a while now, all of our packages were migrated back during the move from 2007 and I was never super motivated to move everything over...in part just due to not having appropriate time to test everything. However, with summer break (we're in education as well) in the wings, I would like to move as much as possible into the Application model. If you could provide more info on your user driven install and uninstall, I would appreciate it. Right now, we are experimenting with a TS which does what you are talking about with your batch files...there are a couple WMIC uninstall command lines that are run in order to uninstall all prior versions of the software, as well as some taskkill commands, and then we install the latest version. I would be curious to see what your batch files look like, if you don't mind thanks for the input!

Anyone?

We are deploying Flash, Java, Quicktime, etc, using the Applications model in CM2012. Our WSUS is not handled by CM, and is handled farther upstream in our AD forest...otherwise, I would use CM to help roll out the Adobe products with SCUP. My question to you all: how do you handle management of added application updates? Just looking at Flash in particular, when adding a new application and setting supercedence, it seems like I'm going to end up with hundreds of entries just for Flash applications that update prior versions. Am I doing it wrong? Do you guys delete the old Application at some point? Or is this just a shortcoming of the Applications model? I can see splitting the Applications into their own folders, in order to help make it easier to manage...but what other current practices are people using? I'm just looking for examples of how people manage their Apps, and how they handle updates to them...any info is appreciated! thanks!

That's odd...here's what I see in our volume licensing download section when I search just for "System Center 2012"...you can see the RTM products, and then below them are their SP1 counterparts.

If you have a volume licensing agreement, then you can download the non-SP1 version there. Unfortunately, just the boot.wim file will not work...it needs to be the "boot.TST0001.wim" file that SCCM creates, so that it has all the CM components with it. Does anyone know what all is included with the modified boot.wim that CM creates? I wouldn't have a problem sharing it out, if I knew for certain that there wasn't any info stored in the those binaries that could be used to compromise my CM environment on some level.

Binarymime, I was following your thread, and it looks like there's a somewhat decent solution now available, which was mentioned early on in the thread, but no exact details given... Unfortunately, the first step is a little tedious as it requires you to setup SCCM in a VM all over again, but I was able to get this to work for our older workstations so it makes it worth it to me... Build an SCCM 2012 RTM server (Site code TST) and copying off the boot.TST0001.wim from D:\Program Files\Microsoft Configuration Manager\OSD\boot\i386 Create a bootable USB using the Task Sequence wizard in you SCCM 2012 SP1 installation Copy the boot.wim, off the newley created USB (D:\sources\boot.wim) and mount the image using DISM. This should be winPE4.0 Browse the mounted image and copy the (d:\sms\bin\i386) to a local drive for later use. Mount the boot.TST0001.wim, which is winPE3.0, and copy the above directory (which should contain all the SMS SP1 OSD functions) into the same location on the mounted wim. Click yes to overwrite all files. Un-Mount and commit the boot.TST0001.wim, rename it to boot.wim and copy to the USB key in place of the WinPE 4.0/Overwriting this What I hadn't thought about at the time, was that you might have been able to find a VM from Microsoft that already had ConfigMgr installed as some sort of trial (if such a thing exists)...this would save you having to setup SCCM 2012 RTM yourself. I would also note that it would be a good idea to add the USB stick drivers to your WinPE image, otherwise you might get an error that says WinPE cannot read from the task sequence disk. Now, what this means is that you're looking at LTI for all your old workstations, and no ZTI...this could be very problematic depending on your organization. Also, I believe that the workaround as was proposed will not allow you to import this boot image into SCCM, because even though it has the 4.0 binaries, I think SCCM will still recognize it as a WinPE 3.0/3.1 image. I'll try here shortly and let you know what happens. [edit] Yeah, it won't let you import the hacked boot image.