Pharos - Get Job Cost Methods of Spool Queues

While working on the migration from one Pharos Uniprint server to another I needed to ensure I had all the Job Cost methods set correctly. You can find this information in the Pharos Administrator but in the older server its is only listed by Clicking the Charging tab. However the information is easy to get with SQL.

Pharos Administrator GUI from 8.0

Pharos Administrator GUI from 8.0 showing Job Cost Method

However to get a list of Spool queues and their job cost methods is a really simple query.

SELECT    dbo.job_cost_methods.name AS 'Job Cost Method', dbo.spool_queues.name AS 'Spool Queues Name'
FROM         dbo.spool_queues INNER JOIN
                      dbo.job_cost_methods ON dbo.job_cost_methods.job_cost_meth_id = dbo.spool_queues.job_cost_meth_id
ORDER BY 'Job Cost Method', 'Spool Queues Name'

Remove or Delete WSD Ports from Windows 2008

Heres a quick post about WSD ports in Microsoft Windows Server 2008.

Normally when you want to delete a printer port you must disconnect any printer using that port before you can delete it. Also deleteing the printer doesn't delete the port attached to it.

However if you try to delete a WSD port you get an error. I found several posts saying you couldn't delete them however the solution was very simple. WSD ports can be deleted by deleteing the printer that is attached to the WSD port.

If you have a WSD port you want to delete just create a Temp Printer that uses that WSD port and then Delete that Temp Printer.

It's counterintuitive to the norm but very workable.

Links
http://blogs.technet.com/b/askperf/archive/2008/02/11/ws2008-the-wsd-port-monitor.aspx

Pharos Web Servies - Uniprint HTTP Error 500.19

I sort of want to start these Pharos Posts like sesame street. Todays error is brought to you by the Number "500.19". If you don't catch the reference don't worry as its not that funny anyway.

So out of the box install of Pharos Web Services on a Windows 2008 R2 64 bit VM. Navigate to the start page and heres what you'll see the following error/greeting. 

Config Error:

There is a duplicate 'system.web.extensions/scripting/scriptResourceHandler' 
section defined"

Config Source
section allowdefinition="MachineToApplication" name="scriptResourceHandler" requirepermission="false" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"

Solution

Not to worry as the fix is a simple one. Following the logic from http://forums.iis.net/t/1149226.aspx. The issue arises becuase its using a .Net 4 Application Pool and unnecessary to load these sections since their loaded in the parent. I tried just commenting out the sections of the web.config that trouble loading when it said there was a duplicate section defined. That worked perfectly so I've included below the resulting working Pharos Uniprint web.config.

Sample of Fixed Pharos Uniprint web.conf

Pharos Interfaces API for Plug-in Scripts

Recently I needed the Pharos Uniprint Plug-in Interfaces to write a few Scripts for our Pharos environment. Interfaces, API, Just something other than taking apart other scripts and guessing at the parameters.

After the trouble finding the normal interfaces that are callable in Pharos Scripts I put in a support call. They replied very promptly however I really find it disappointing that i would really need to use a service all to find it. Maybe you found it but i searched the CD, Chm files, and online with no luck.

Anyway Pharos support got back with and sent me this.

You may find the Pharos Scripting Language Primer by going into Pharos Administrator, and navigating to the Help column in the Menu bar, and go to Help Topics. Then search for Pharos Scripting Language Primer, or go to Pharos Administrator\Technical Information\Pharos Script Primer. You should find what you need there.

And sure enough that was exactally what i was looking for. Its found on the CD under "CD Root\help\Pharos.CHM" open that and then navigate to Technical Information. Look at both Plug-in Interfaces and Pharos Script Primer.

Note: Here is a copy of some of it in hopes that google will lead others here so they can find what I couldn't
Pharos Scripting Language primer and then Plug-in Interfaces below.

Pharos Scripting Language Primer and then Plugin Interfaces below that.

Pharos - Message about your print job

Today while working on migrating our clients from one Pharos Server to a new Pharos Server. I noticed that this popup was seen on the old Pharos system but no the new one.

Pharos "Message about your print job" popup dialog

Since I use several Pharos Scripts in the plug-in's I figured the text for this message must exist somewhere in the scripts. After searching in vain I could not track down the differences in two server's scripts. Finally I found the cause for this message was not in the scripts but rather the Uniprint Global Settings.

Pharos - Uniprint Global Settings

By checking Cost Information and Cost Acceptance the user is notified with the Message about your print Job. Read more about this feature here

This was really a problem for us as I was also using a script to prompt the users to accept charges in another script. Its been that way for 3 years and yet no one as ever complained about having to accept the charges twice. 

Pharos ADLDAP Bank Configuration

Update - 2-5-2013 : Along with this ADLDAPLogon.exe I now use a script to to call it to resolve some issues it has.

This post is about testing and configuring the "ADLDAP Bank" in Pharos.I'll be working from an Pharos 8.1 install on Windows 2008 R2.

You can check that the "ADLDAP Bank"is selected by looking in "Pharos Administrator ->  System -> Print Server -> Bank". If "ADLDAP Bank" is selected we need to go to command line to configure the bank. Open a administrative command prompt and navigate the the following folder and run the list servers option.

cd "c:\Program Files (x86)\Pharos\Bin\"
adldaplogon.exe --list-servers

If only a black line is printed then their aren't any AD servers specified to authenticate against so it fails to return anything when the the bank is called. review the output from logon canceled by plug-in post. Why it doesn't reply that the "Pharos Bank ADLADAP is not configured" is really beyond me.

Anyway we will need a AD account and its username and password. It must belong to a user that the plug-in can use to access the LDAP database; this only needs to be an ordinary user, with no special privileges. however make sure the account doesn't have password expiration enabled on it. I created a service account special for this and labeled it as such aka. pharosldap.

Pharos - Logon cancelled by plug-in

Working with Pharos 8.1 on Windows 2008 R2 configured to use AD Authentication. Pharos clients are getting "Print job 'Untitled - Notepad' failed: Logon cancelled by plug-in" popup message after correctly entering valid credentials.

Pharos Client popup - Logon Cancelled by Plug-in

Looking at the alert error from in "Pharos Administrator -> System -> Alerts" doesn't show a lot more information as to the cause of the message.

Pharos - Pharos Admin Alert for Logon Cancelled by plug-in

To get more information we have to enable the Pharos Print Server logs. To do this follow my other post on how to enable the Pharos Print Server Logging. Once that is done and the Pharos Print Server has been restarted so logging changes take effect, print from the client again which should cause the "Logon cancelled by plug-in" error again and then look at the log.

Configuring Pharos Logging Settings - Pharos Log Setter

By default Pharos Server and client software doesn't do much in they way of logging.  Thats the bad news, the good news is it can log nearly everything we need to trouble shoot stuff if enabled them. This post should give you enough information to enable and disable the Pharos Print Server logs. This really hasn't changed since version 5 through version 8.1 of Pharos.

However for starters we want to be organized as to where we want Pharos to store its log files. This will make our life much easier later rather than looking all over for them. Create a logs folder in which we'll point any logging files we have Pharos generate. Create folder  "C:\Program Files (x86)\Pharos\Logs" if it doesn't exist.

Also A piece of house keeping, any changes to the logging settings requires a reboot of the pharos service associated with that log.

We have two ways of configuring Pharos Logging.

Method 1 - Using Pharos Log Setter

On the Pharos Installation CD there is a folder "<CD Root>\tools\utils\Logsetter"

Copy the entire logsetter folder to the "C:\Program Files (x86)\Pharos\Logs\" folder we created. This is just so we don't need the CD again (most of use have it as ISO and never burned it but anyway) and the next time it will be easier to get to. Launch logsetter.exe from "C:\Program Files (x86)\Pharos\Logs\Logsetter" and enable the logging you require.

All this app does is set the same keys in the registry that we would of set manually. I use the registry myself but really up to you. Also notice you can set logging levels for "Pharos Database Server", "Pharos License Server", "Pharos Print Server", "Pharos LPD Server", "Pharos Popup Server" and "Pharos Administrator".

Pharos Log Setter

After any Changes a server restart is require for the logging level and enabling or disable to take affect.

Method 2 - Modifying the registry

Then there is always the method of just modifying the registry directly to set the logging options we want.

For example set the following key.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Pharos\Print Server\Log = "C:\Program Files (x86)\Pharos\Logs\PrintServerLog.txt"

In that same registry location we call also change the logging level.

Don't forget to restart the services for Logging settings to take effect.

Important Note: Since these log files can get so large I find it useful to stop the service after i make a logging level change or just trouble shooting a problem. Delete the log file and then restart the service. This prevents me from having to know where at in the log this service started logging.

Links
http://pharos.custhelp.com/app/answers/detail/a_id/626/~/pharos-logsetter-utility

Pharos UniPrint - Print Queue Not Found

I've done a far amount of work with Pharos Systems, in particular, Uniprint.  Honestly I hate the product but thats what I'm forced to work with it anyway. One thing I've always hated about it was the complete lack of any results when researching problems online and by lacking I mean normally ZERO RESULTS. As such you should see large number of posts as I work on migrating our Pharos Print Servers from Windows 2003 to a new Windows 2008 R2 environment. Hopefully someone else finds these useful.

Here's an example of problems I've seen people run into.

If you install the Pharos package on a client and then attempted to print to it you may get this following "Print Queue can Found" popup. Thats your only hint, nothing else as there appears to be no error log of this anywhere on the client side. Later I'll tell you where to enable some logging for this but for this example the solution is simple. The only cause I've seen for this so far was because a Change Control is needed on Pharos server due to queue was just created or maybe a name change.

Pharos Popup Message - Print Queue Not Found

To enable that logging on the client popup you can insert the folling registry value.

To get errors back from the popup client you need to enable it to log to a file.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Pharos\Popup Monitor\Log\Filename = "C:\Program Files (x86)\Pharos\bin\Popuplog.txt"

Here is an example output of the this Popuplog.txt log.

[2011/02/11 12:47:46 P548 T1318 d] -> NPM::StartDocPort
[2011/02/11 12:47:46 P548 T1318 d] [NPM::StartDocPort] hPort=0x00000000045EF770 pPrinterName='AC220_1 on DEVPHAROSSERV1' JobId=00016 Level=1 pDocInfo=0x00000000042FEF08 {pDocName='Untitled - Notepad' pOutputFile='(null)' pDatatype='RAW'}
[2011/02/11 12:47:46 P548 T1318 d] -> SPrintInfo::StartDocPort
[2011/02/11 12:47:46 P548 T1318 i] PrintServer:DEVPHAROSSERV1
[2011/02/11 12:47:46 P548 T1318 i] PrintServerIpAddress:DEVPHAROSSERV1
[2011/02/11 12:47:46 P548 T1318 i] SpoolQueue:AC220_1
[2011/02/11 12:47:46 P548 T1318 d] -> SPrintInfo::GetJobFilePathAndName
[2011/02/11 12:47:46 P548 T1318 d] <- SPrintInfo::GetJobFilePathAndName
[2011/02/11 12:47:46 P548 T1318 i] WorkStation(MachinaName):\\LABVM2
[2011/02/11 12:47:46 P548 T1318 i] UserName:towlesd
[2011/02/11 12:47:46 P548 T1318 i] Document:Untitled - Notepad
[2011/02/11 12:47:46 P548 T1318 i] Pages:1
[2011/02/11 12:47:46 P548 T1318 d] -> SPrintInfo::FreePopupData
[2011/02/11 12:47:46 P548 T1318 d] <- SPrintInfo::FreePopupData
[2011/02/11 12:47:46 P548 T1318 d] -> StartPopupClient
[2011/02/11 12:47:46 P548 T1318 d] -> ExecPopupClient
[2011/02/11 12:47:46 P548 T1318 i] Pharos Path:C:\Program Files (x86)\Pharos
[2011/02/11 12:47:46 P548 T1318 i] Exec Popup Client:C:\Program Files (x86)\Pharos\bin\POPUPCLI.EXE "Global\aa0c04aa-adf3-4765-b542-62b153b5f24e"
[2011/02/11 12:47:46 P548 T1318 d] -> CreateProcessInUserSessionAndWait
[2011/02/11 12:47:49 P548 T1318 d] <- CreateProcessInUserSessionAndWait
[2011/02/11 12:47:49 P548 T1318 i] Exec Popup Client, result=1, exit code =0
[2011/02/11 12:47:49 P548 T1318 d] <- ExecPopupClient
[2011/02/11 12:47:49 P548 T1318 d] <- StartPopupClient
[2011/02/11 12:47:49 P548 T1318 d] <- SPrintInfo::StartDocPort
[2011/02/11 12:47:49 P548 T1318 d] <- NPM::StartDocPort
[2011/02/11 12:47:49 P548 T1318 d] -> NPM::WritePort
[2011/02/11 12:47:49 P548 T1318 d] [NPM::WritePort] hPort=0x00000000045EF770 pBuffer=0x00000000048151D0 cbBuf=33965
[2011/02/11 12:47:49 P548 T1318 d] <- NPM::WritePort
[2011/02/11 12:47:49 P548 T1318 d] -> NPM::EndDocPort
[2011/02/11 12:47:49 P548 T1318 d] [NPM::EndDocPort] hPort=0x00000000045EF770
[2011/02/11 12:47:49 P548 T1318 d] -> SPrintInfo::EndDocPort
[2011/02/11 12:47:49 P548 T1318 d] -> SPrintInfo::FreePopupData
[2011/02/11 12:47:49 P548 T1318 d] <- SPrintInfo::FreePopupData
[2011/02/11 12:47:49 P548 T1318 d] -> SPrintInfo::Cleanup
[2011/02/11 12:47:49 P548 T1318 d] -> SPrintInfo::GetJobFilePathAndName
[2011/02/11 12:47:49 P548 T1318 d] <- SPrintInfo::GetJobFilePathAndName
[2011/02/11 12:47:49 P548 T1318 d] <- SPrintInfo::Cleanup
[2011/02/11 12:47:49 P548 T1318 d] <- SPrintInfo::EndDocPort
[2011/02/11 12:47:49 P548 T1318 d] <- NPM::EndDocPort

How to Update VMware View Server's Client Installer from Website

With the recent Vmware View Client build updates to fix problems with Microsoft KB 2482017 Microsoft KB 246702 and my other post. I figured I'd post how to update the VMware View Server website so that future clients get the new build as this change is really easy.

First download the newest client from here. Save both the 32 bit and 64 bit versions as will need to copy them to the server. Next we need to browse the folder structure of our VMware View Server to the following location.

"\\<ViewServer>\c$\Program Files\VMware\VMware View\Server\broker\webapps\downloads.war"

It should look something like this.

All we really need to do is copy the software we already downloaded. (VMware-viewclient-4.5.0-353760.exe and VMware-viewclient-x86_64-4.5.0-353760.exe) and rename them in the folder to match the already existing files.

So backup somewhere first then delete VMware-viewclient.exe and VMware-viewclient-x86_64.exe files.

Then rename VMware-viewclient-4.5.0-353760.exe to VMware-viewclient.exe and copy and replace it to the downloads.war folder.

Do the same VMware-viewclient-x86_64-4.5.0-353760.exe renaming it to VMware-viewclient-x86_64.exe copy and replace it to the downloads.war folder.

To test that this works navgate to https://YourViewServer/ and download the 32 bit and 64 bit clients. Save them and right click the exe's and open the properties on the filies. Go to details and notice the new product version shows the correct build number.

As for fixing existing clients they must uninstall the previous version, you could wrap these exe's so that they first uninstalled any previous versions and then installed the wrapped version. Let me know if anyone has problems following this.

VMware View Windows 7 Client can't Connect to View Sever

Update 3 on 2011-04-22 - It was pointed out that I never said here that rather uninstalling these patches you really should have users update their client build that was released by Vmware the day after the Microsoft patches were released. I talk here about how to offer the cleint to your users.

Content below this is outdated.


Update 2 on 2011-02-10 - I wrote up a post here on how to load the new Vmware Client Build into your view server so that clients can download it instead of the old build.

Update 1 on 2011-02-09 - the VMware KB below was actually change to list the two Mircrosoft KB's I listed here. Also they changed the fix as update the Vmware View Client.

This morning we found our lab of Windows 7 View Clients all unable to connect to the View Server. They weren't able to even get the the user login prompt. Instead the Windows 7 View Clients would say connecting and they seem to lockup the View process.  The cause turns out the be windows updates released this morning.

Vmware Posed a KB on the issue (Unable to connect from the Windows 7 Client to the View Connection Server after installing the patch in Microsoft Knowledge Base article 2482017) however VMware only listed Windows KB 2482017 as the problem. Uninstalling this patch only only seemed to make the failing connection fail out rather than locking up.

Solution
We found that uninstalling that alone doesn't resolve the problem and yes we allowed reboots. However by removing both Microsoft update KB2482017 and KB2467023 together restored the machine to proper working order.

Uninstall
Microsoft KB 2482017
Microsoft KB 2467023

Sysprep and Settings Autologon Keys with FirstLogonCommands

Ran into small problem today when setting up a Vmware View Repurposed Thin Client. The behavior i wanted has the Windows 7 machine running sysprep. On first boot it autologon's to the local administrator account. On that first logon it runs all the nessary FirstLogonCommands from the sysrep unattended file. In those commands are the nessary commands to change the autologon to have it login to a local viewuser account that has had it window shell replaced. The problem was that the FirstLogonCommands where failing at setting the autologon registry keys correctly.

Problem
It turns out that because AutoLogonCount is set to 1, on logon it decrements it to zero. On logoff and reboot when Windows 7 sees the AutoLogonCount set to zero it deletes the keys "AutoAdminLogon", "AutoLogonCount", and "DefaultPassword" from the registry. Those same values I had just set for the ViewUser.

Solution
The easy solution is easy, I just have to add a command to delete the AutoAdminLogon key from the registry my self. Then Windows never goes back and cleans up the Auto Logon Registry keys that where just set.

<AutoLogon>
    <Password>
        <Value>password</Value>
        <PlainText>true</PlainText>
    </Password>
    <Domain>.</Domain>
    <Enabled>true</Enabled>
    <LogonCount>1</LogonCount>
    <Username>Administrator</Username>
</AutoLogon>

This is how it will look in the sysprep unattended file to set the autologon after the administrator autologon.

      <SynchronousCommand wcm:action="add">
        <CommandLine>cmd /c reg.exe delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /f /v AutoLogonCount</CommandLine>
        <Description>Remove AutoLogonCount so that other autologon settings stay</Description>
        <Order>18</Order>
        <RequiresUserInput>false</RequiresUserInput>
      </SynchronousCommand>
      <SynchronousCommand wcm:action="add">
        <CommandLine>cmd /c reg.exe add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /f /v DefaultDomainName /t Reg_SZ /d .</CommandLine>
        <Description>Set default Domain for autologon</Description>
        <Order>19</Order>
        <RequiresUserInput>false</RequiresUserInput>
      </SynchronousCommand>
      <SynchronousCommand wcm:action="add">
        <CommandLine>cmd /c reg.exe add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /f /v DefaultUserName /t Reg_SZ /d ViewUser</CommandLine>
        <Description>Set default UserName for autologon</Description>
        <Order>20</Order>
        <RequiresUserInput>false</RequiresUserInput>
      </SynchronousCommand>
      <SynchronousCommand wcm:action="add">
        <CommandLine>cmd /c reg.exe add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /f /v DefaultPassword /t Reg_SZ /d password</CommandLine>
        <Description>Set default Password for autologon</Description>
        <Order>21</Order>
        <RequiresUserInput>false</RequiresUserInput>
      </SynchronousCommand>
      <SynchronousCommand wcm:action="add">
        <CommandLine>cmd /c reg.exe add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /f /v AutoAdminLogon /t Reg_SZ /d 1</CommandLine>
        <Description>Set AutoLogon to enabled </Description>
        <Order>22</Order>

Password Manager Pro Service doesn't start Database (mysql)

At work we use and recommend "ManageEngine Password Manager Pro". However lately we've had a problem with the Password Manager Pro Windows Service would not start correctly. For reasons that were not clear; the service would stop seconds after starting. After looking into it I found that the mysql process was never being launched. As a part time fix I created a bat file on the server to manually start the Password Manager Pro Database. However this only worked as long as my account stayed logged into the machine.

cd "\Program Files (x86)\PMP\bin"
startdb.bat 2345
pause

Final Solution
After a support call with ManageEngine they reported the following.

Please add the path for 'findstr' in the environmental variables. You can Right Click My Computer-->Properties-->Advanced Tab-->Environmental Variables and add the path of the findstr.exe file which will be in WINDOWS\system32 folder. We use findstr command to fetch the database password which is present in databaseparams.conf file for starting the database while you start PMP from services console.

However looking at the system path variable it included "C:\Windows\system32", upon further looking by setting the service to start with a user account. And then making sure that user account had "C:\Windows\system32" in their user variable resolved the service problems. Not the best solution but a workable one.

Environment Variables