Scripting Sybase PowerDesigner Viewer 16.x

Ran into a curious situation when automating the installation of Sybase PowerDesigner Viewer 16.  If you just want the answer, then jump to the bottom of this post :-)

The installer was built as a self-extracting InstallShield setup.  Typically, for a ConfigMgr package I like to use the extracted files.  However, when attempting to run the Setup of the InstallShield installation, an error was generated that “setup.cab” was missing from “Disk2″.  This was issue #1.

Since there was no “disk 2″, so I reverted back to just using the native, self-extracting installer.  This appeared like it was going to be fairly simple as all defaults were going to be used.  Most times, just using /s is enough to complete the silent installation.  But no, this would be too easy.  The installation would still not run unattended.  Eventually I discovered that the only way to automate a silent installation was to create and include a setup.iss record file.  Again, this is despite that only the defaults were being used and that a basic setup.iss was already included as part of the extracted files.  This was issue #2.

So have we finally figured out how to automate the silent install?  Of course not – there is no reason that a simple application should be so easy to automate.  Running the install as PDV_16.exe /s /f1″setup.iss” would absolutely install PDV…when executed manually.  As soon as it was deployed using ConfigMgr, the setup would fail with an error.  Why oh why!?!  Turns out that their installer also hates to be run in System context.  Which is what we all know is how ConfigMgr needs to do it, especially for Task Sequences.  This was issue #3.

After tussling with this application, I finally figured out that not only is a recorded installation (setup.iss) necessary, but so is specifying a location for the log file!!  Conclusion?  I despise Sybase installers.  Answer?  Use the following command line.

PDV_16.exe /s /f1"setup.iss" /f2"c:\windows\temp\pdvsetup.log"

One last comment.  Make sure the log file is specified in a directory that already exists (such as c:\windows\temp), otherwise you end up with Issue #4.  And use a wrapper (such as a batch file) to specify the current working directory of the setup.iss file, otherwise you’ll end up with Issue #5.  If using a batch file, the command would like this for your ConfigMgr package:

"%~dp0PDV_16.exe" /s /f1"%~dp0setup.iss" /f2"c:\windows\temp\pdvsetup.log"

Ping Transport Failed with Error 1231

Recently I was helping a friend with her laptop which suddenly stopped connecting to the Internet, despite that the wireless networking could see and successfully connect to wireless hotspots. In further troubleshooting, I noticed that the correct IP address range (192.168.0.x) was not handed out by the router’s DNS. Furthermore, when attempting to ping the router’s gateway (192.168.0.1) with “Ping Transport Failed, Error 1231“. Digging through the Internet on this error, I found the possible solution buried deep within a couple Microsoft forum threads. I’m posting it here so that if it should ever occur again, hopefully the solution is quicker to find!

1. Open a command prompt with Run As Administrator
2. Run “netsh winsock reset”
3. Restart Windows

Now the system is back in business!

Installing VMware View Agent in a Task Sequence

The VMware View agent is deployable as an MSI file and uses basic command line parameters.  However, I recently had significant difficulties with getting it to install within a ConfigMgr Task Sequence as part of an OS image deployment.  Despite that the agent could be installed manually using the parameters, in a TS the installer would fail (e.g. return a non-success exit code) and thus fail the TS.

Through investigation, the agent’s install log file (located in %windir%\temp\) stated error 1603 and a message that if failed due to a detected pending restart.  So in the TS, I added a pre-restart command prior to the install…..but that still did not solve the problem.  Several various other solutions were attempted, but all to no avail.

Eventually I found a VMware KB article which outlined the issue.  It was being caused by multiple registry keys – FileRenameOperations, Run, and RunOnce.  So I created  a quick batch script to

1. Backup the reg keys to %windir%\temp
2. Delete the reg keys
3. Run the install
4. Restore the reg keys

:: Backup problem registry keys for VMware Agent Install
reg.exe EXPORT "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" c:\windows\temp\hklmsession.reg /y
reg.exe EXPORT "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" c:\windows\temp\hklmrun.reg /y
reg.exe EXPORT "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce" c:\windows\temp\hklmrunonce.reg /y

:: Delete problematic registry keys
reg.exe DELETE "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v PendingFileRenameOperations /f
reg.exe DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /va /f
reg.exe DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce" /va /f

:: Install VMware agent
xcopy "%~dp0VMware-viewagent-x86_64-5.0.1-640055.exe" c:\windows\temp /y
c:\windows\temp\VMware-viewagent-x86_64-5.0.1-640055.exe /s /v" /qn REBOOT=R"

:: Restore registry keys
reg.exe IMPORT c:\windows\temp\hklmsession.reg
reg.exe IMPORT c:\windows\temp\hklmrun.reg
reg.exe IMPORT c:\windows\temp\hklmrunonce.reg

del c:\windows\temp\hklm*.reg
exit

However, this still wasn’t good enough to solve the problem! The .msi needed to be copied locally to execute AND this needed to be run with 64-bit redirection disabled.  It was a mess to figure out and test, but I was able to eventually discover the right combination to have the agent automatically in a Task Sequence!

Another copy of Configuration Manager Setup is already running

Recently built myself a new server for my home lab and decided to build out a new domain. During the setup process of CM12 SP1 (on Win 2012 with SQL 2012 SP1 CU2), the guest VM hung midway through setup and was completely unresponsive.  So I reset the VM and ran the CM12 SP1 setup again – it only allowed the site to be uninstalled, which I did.  However after immediately trying to install CM12 again, I received error “Another copy of Configuration Manager Setup is already running”.

The fix?

Just restart the server after the uninstall of the site.

Error initializing client registration (0×80040222)

I recently had a request from a customer to rename their PCs during an in-place upgrade of WinXP to Win7.  I’ve put together some custom scripts to detect the particular qualifying conditions for when the PC needs to be renamed, and these scripts work just fine (this is an upcoming blog post).

The problem that I ran into was that after completion of the task sequence, the CM07 client was unable to register with the site server.  Thereby it wouldn’t receive policies and did not operate.  The client’s ClientIDManagerStartup.log showed “Error initializing client registration (0×80040222)”.  As part of my troubleshooting, I was able to “fix” the client by deleting the old computer record instance and the generate a new GUID on the client.

Credit to one of my colleagues who was able to identify the scenario when I had overlooked it.  The real problem was that since the PC was being renamed, a Conflicting Record was being created since both the old and new instance had the same hardware ID information.  There are two ways to resolve this situation:

1. Manually resolve the conflicting records
2. Configure the site to automatically resolve the conflicting records

Option 2 is the most desirable since you can set it and forget it….so that’s we did!

 

 

Failed in WinHttpSendRequest API, ErrorCode 0x2ee7

Ran into a situation where all CM07 clients at a particular site were not installed/active within the ConfigMgr primary site.  Digging into the ccmexec.log file on the clients, errors were generated repeatedly with message “Failed in WinHttpSendRequest API 0x2ee7″.  In this particular scenario, I discovered that the client was attempting to communicate with the MP when the error occurred…and that the server’s name was incorrect.  So instead of trying to reach ServerA01, it was trying to reach ServerA (note the missing zero+one at the end of the name).  Turns out that when the Secondary Site was set up, whomever had created the site mistyped the name.

To fix this, the following needed to happen for me to eventually get this to work.

1. Update the Secondary Site’s specified FQDN to be the correct name as ServerA01
2. Uninstall the proxy MP on the secondary
3. Manually delete the SMS-MP records in the Systems Management container.  I had to do this because for some reason the site didn’t have the correct permissions, even though it really did.
4. …wait
5. Reinstall the proxy MP
6. Regenerate new GUIDs for the clients at the site (I used the SCCM Client Center tool to perform this).  I had to generate the new GUIDs because they were not receiving the corrected FQDN server name on their own.

And within minutes, all was clear and clients were functioning again!

ACT 5.6 Log Processing Error 1017

Recently came across a situation where my ACT 5.6 server suddenly ceased processing log files and the directory had filled up with .cab files.  As I had previously learned, the first quick thing to check is that the log processing [Windows] service is started.  In this case it was started, but the .cab files were stuck.  In turning to the event logs, I there was a warning message for ACT-LPS code 1017 with message “listener.exe verification for directory \\server\share fails”.

As it turns out, the fix was simple.  Somehow ACT had accidentally become configured to just use the \\ServerName\ and it did not have the logs directory.  By resetting it to include the correct path, the service began processing all the logs again!

Website for associating WUA with MS updates

If you’re having problems with detecting updates for Microsoft Office, there is a good chance that the Windows Update Agent (WUA) is not associated with “Microsoft Update”.  One way to fix this on a per-computer basis is to use a MS website which will do this for you.  It is http://update.microsoft.com/microsoftupdate/v6.

CM12 Software Updates Gotcha

An added feature to ConfigMgr 2012 is the ability to directly deploy software updates without them being a deployment group.  This can result in a “gotcha” moment when update are incidentally deployed to systems.  This situation occurred to me recently when IE9 was deployed to a collection (fortunately non-mandatory!) but I could not find that update in any deployment group.  If it has been deployed as part of many updates, then this would have never occurred and I could have easily removed the update.

The way to get yourself into this predicament is by doing the following.  Note: this is just a lesson, don’t actually do this in production!

1. In the console, navigate to Software Library > Software Updates > All Software Updates
2. Select a single updates to install
3. Select “Deploy” on the wunderbar
4. Note that in the first page of the wizard, it LOOKS like you’re adding updates into a software update group.
5. Finish the wizard with whatever settings (please don’t make this a Required install, lest you screw yourself)

Now go into node Software Update Groups.  Where is the deployment group that was supposed just created?  It isn’t there!!  To then delete the deployment, find an individual update, go to the Deployment “tab” and delete the deployment.  Note how the update group says “Individual”

To prevent this from accidentally occurring to you, a general rule of thumb is to add the update(s) to be installed into a new or existing Software Update Group and then deploy that group to a collection.

Reporting Services Site Role Setup: Instance Blank/Empty

When attempting to set up and configure the ConfigMgr 2012 site system role for reporting services, a frequently experienced “problem” is that the instance name can be blank/empty in the wizard and thereby unable to proceed with the wizard.  This usually occurs when SRS has not been pre-configured properly.

While it is common “knowledge” that the reporting services database needs to be created first, an oft-overlooked step is to use the Reporting Services Configuration Manager to create the virtual directories for IIS.  And it is these steps which need to be completed to get you on your way.

1. Open Reporting Services Configuration Manager
2. Connect to the server/instance
3. Click on Web Service URL – make a fake change, such as changing the name of the virtual directory and then putting it back to ReportServer – and clicking Apply.  This will then create the new virtual directories.
   
4. Click on Report Manager URL – again, make a change to the name and put back to just Reports – and click Apply to generate the new virtual directories.
5. Close configuration manager
6. Return to the CM12 site role setup program, click “Verify” for the database connection, and voila the instance is now populated correctly!