I had a project recently that required a PC to open a Internet Explorer session at start up in kiosk mode:
iexplore.exe -k (web address)
I had a project recently that required a PC to open a Internet Explorer session at start up in kiosk mode:
iexplore.exe -k (web address)
I have had this issue out of the blue. MDT had been working flawlessly for around 2 years and then recently I kept getting to a point in a deployment when it would go no further.
When you are prompted for user, password and domain details so that the \\deploymentshare could be accessed I would either receive the errors:
Invalid credentials: The network path was not found
or
A Connection to the deployment share (\\computername\share\) could not be made. The
deployment will not proceed.
After a search on the Internet someone suggested changing the server name in the
bootstrap.ini from the ser ver name to include the FQDN i.e. \\mdt server\deploymentshare$ -> \\mdtserver.mycompany.com\deploymentshare$
This made no difference and I was beginning to think that this was a networking issue or port block issue of some kind.
Instead of using the FQDN I changed this to the IP address of the server i.e. \\1.2.3.4\\deploymentshare$
After updating the deployment share and then replacing the boot image used by WDS this resolved the problem.
I can only assume that there is some kind of authentication issue within Windows perhaps as a result of a Windows update
After you have moved an Outlook account and associated .pst file to a different location or PC you may receive this error after you try to Send/Receive mail.
I found that the problem was caused by the expected delivery locations for the send/receive process.
I found that by changing the folder to specify a different inbox, applying and then selecting the correct inbox and applying fixed the issue.
- In Outlook 2010 click File>Account Settings>Account Settings
- Select the relevant account and click Change Folder
- Select a different location and apply
- Select Change Folder and select the correct Inbox location
The send/receive process should now work
I found this to be a problem on a client running GroupWise v8. When they right clicked on a message and selected properties they were prompted to download and install GW}00001.TMP. Clicking cancel left the message properties tab with a ‘Page cannot be displayed’ message.
I tried uninstalling and reinstalling the GroupWise client which didn’t resolve it. I found information on a Novell forum here http://forums.novell.com/novell/novell-product-discussion-forums/groupwise/groupwise-7x/gw7-clients/100739-cannot-view-mail-properties-gw7-01-a.html which mentioned that this was an issue with MSXML.
I then found official support here http://www.novell.com/communities/node/6968/properties-groupwise-message-prompts-install-gw00001tmp
When I tried to unregister and reregister the msxml4.dll I got an error message stating that it had failed as the dll didn’t exist.
Next I downloaded MSXML 4.0 Service Pack 3 (Microsoft XML Core Services) from
http://www.microsoft.com/download/en/details.aspx?id=15697
After installing this cleared the issue immediately.
After some research I found that you can only be authenticated to the NDS Tree once unlike AD where you can ‘Run As’ under a different AD account.
In the end I just created a batch file that the logged on user manually runs so that their credentials are used instead.
After I had created a new command and then a new HP ASR monitoring service I found that when I went to commit the portion of the screen on the right just went blank and nothing happened.
I looked back at the command I had created and there was no detail in the right hand side which should have been populated with the Command Wizard window that includes the specific command configuration and details.
I assumed then that the issue was caused by the command and that it had become in some way corrupt.
When you create an entity within Groundwork such as a host, service, command etc it is written to the Monarch database. Once it is committed it is then also added to the Nagios config files in.
So it is simple – remove the specific command entry from the commands table in the Monarch database.
Except it wasn’t. I wanted to install MySQL workbench on the CentOS server hosting Groundwork. I just couldn’t get it to load. Then I couldn’t open MySQL from the command line and was receiving a variety of errors. After much trial and error this is how I managed to delete the offending command entry from the Monarch database.
1. Installed MySQL Workbench on my Windows 7 client
Need to allow remote access to the MySQL database
MySQL looks at the file my.cnf when opening the mysql client. You will get an error when trying to open the client because MySQL is looking at the /etc/my.cnf rather than /usr/local/groundwork/mysql/my.cnf
This can be done remotely using putty or on a terminal window on the server itself
2. Backup or take a copy of /etc/my.cnf and overwrite with the /usr/local/groundwork/mysql/my.cnf version
3. Stop and restart gwservices which will restart MySQL
/etc/init.d/groundwork stop
/etc/init.d/groundwork start
4. Open mysql by typing mysql
5. Type GRANT ALL PRIVILEGES ON *.* TO username@yourclientIPaddress;
For example GRANT ALL PRIVILEGES ON *.* TO root@158.3.2.6;
6. Connect to the MySQL instance via MySQL Workbench
7. Locate the Monarch database and select the relevant table
8. Edit the table data and remove the row entry that contains the corrupt record
9. Select Apply changes to data
10. Check within Groundwork and Configuration whether the offending record has gone
11. I stopped Groundwork services and added back the original my.cnf to /etc/my.cnf and restarted the server to complete

In my ongoing mission to troubleshoot a problem with Groundwork and Nagios I keep stumbling upon random errors which set me back each time. This time after I had made some changes to the /etc/my.cnf file as this seemed to be referenced rather than the /usr/local/groundwork/mysql/my.cnf file. I chose to copy the contents of the /usr/local/groundwork/mysql/my.cnf file to the /etc/my.cnf which amongst other things allowed me to connect remotely using MySQL Workbench. However after a reboot the portal would no longer load and there was a number of Java reported errors as below.
After I had completed the MySQL admin I simply restored the original /etc/my.cnf file which instantly resolved the problem
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented it from fulfilling this request.
exception
javax.servlet.ServletException: java.lang.NullPointerException
org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:278)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
root cause
java.lang.NullPointerException
org.jboss.portal.core.impl.model.portal.PersistentPortalObjectContainer.getObjectNode(PersistentPortalObjectContainer.java:252)
org.jboss.portal.core.impl.model.portal.AbstractPortalObjectContainer.getContext(AbstractPortalObjectContainer.java:112)
org.jboss.portal.core.impl.model.portal.AbstractPortalObjectContainer.getContext(AbstractPortalObjectContainer.java:81)
org.jboss.portal.core.model.portal.DefaultPortalCommandFactory.doMapping(DefaultPortalCommandFactory.java:72)
org.jboss.portal.core.controller.Controller.handle(Controller.java:252)
org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestControllerDispatcher.java:51)
org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:131)
org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:252)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
note The full stack trace of the root cause is available in the JBossWeb/2.0.1.GA logs.
Make sure that your my.cnf in /etc is actually pointing to the correct MySQL instance
I found MySQL installed within a different location (for Groundwork Community Edition) with its own my.cnf file
I overwrote the /etc/my.cnf file with the values in usr/local/groundwork/mysql/my.cnf
You receive the error
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
It was a relative easy solution. Simply add the hostname in /etc/hosts:
127.0.0.1 localhost.localdomain your_hostname
For example:
10.32.1.2 nagiossrv.adir nagiossrv