shawn

Never mind, there was a 3rd party tool blocking the application from displaying but wasn't blocking the package. Fun...

Thanks for the info. I do have access to Admin Studio but was hesitant due to time constraints and that the install packages AJAX.NET 2.0. So you think this issue with working as a Package vs an Application is more related to the fact that i'm using AutoIT?

Hello, I have a program that uses an old installer without any silent options. I've created a AutoIT script that clicks on the buttons of the setup program when it launches. When using this program within a SCCM Package, the setup launches to the screen visible to the user. But when I run it as a SCCM Application the setup is not visible to the user and the AutoIT script fails. There are several differences between the wording in Package and Application; in Application it's "Install for user", in Package, its "Run with user's rights". Are these interchangeable? In the Package i have "Allow users to interact with this program" and in the Application i have "Allow users to view and interact with the program installation" selected. It would have been nice to use an Application for this but if I need to use a Package that's fine. My question is why this is happening. Any ideas? Thanks, Shawn

What I like to do is to install the application and then go to "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" in the registry and see if there is an entry for the windows installer code for the application. If there is you can use that for the detection method. Click on each key and look for the DisplayName entry to match to your application name. Also make sure to check Wow6432Node if it's a 64 bit system. When you find your application copy the entire key name and use that for the detection method. So your detection method might be {26BFF1F1-5C03-4C55-9C7C-FD65889AFA70}. In the detection rule settings, choose Windows Installer. Not all applications use this especially if they are an exe based installer but i've found that most do. If there is an easier way than this I would like to know also. Thanks, Shawn

Hello, Our old image that we created would join the computer to the domain at the end of the OSD task sequence. With our new image it does not join itself and there do not appear to be any noticable logs entries that have anything to do with adding to the domain in the 'C:\Windows\syswow64\ccm\logs' folder. We use MDT 2010 with the UDI Wizard. The old image was a 64 bit Windows 7. The new image is a 64 bit SP1 Windows 7. The only real difference would be the added Windows updates included within SP1. To build the image we used the Build and Capture process described on this website. The only difference is we broke the build and capture into two steps so that we could apply additional windows updates We found a post that talked about checking the C:\Windows\debug\netlogon.log. lpMachineAccountOU: (NULL) is something that we noticed was different. The old image had the full domain ou in this entry. The only thing we did in the task sequence was to change the step Apply Operating System Image to the new image. Any ideas would be appreciated. Thanks, Shawn

Hello, We are having an issue using USMT Side by Side. We have gotten In-Place to work but not Side by Side. We are attempting to use SMP. In the SMSTS log we get OSDStateStorePath TS Environmental variable is empty. Failed to construct commandline. There are no scanstate or loadstate logs. We are relatively new to USMT and are pulling our hair out trying to make this work. Any help or direction you could give us would be appreciated. Thanks, Shawn