I am noticing a delay of 5 to 15 seconds when printing using the DYMO Label Web Service starting this morning, 4/23/2018. This happens on multiple PCs on all browsers. On a Mac it works fine.
The log at %LocalAppData%\DYMO\DLS8\DLSWebService.log seems to show the delay. I don't see any errors in the Console beyond the usual Synchronous XMLHttpRequest on the main thread is deprecated warning.
DYMO.DLS.Printing.Host.exe Information: 0 : PrintLabel: DYMO LabelWriter 450 Turbo
DateTime=2018-04-23T17:08:34.9541652Z
DYMO.DLS.Printing.Host.exe Information: 0 : Loading barcode lib from C:\Program Files (x86)\DYMO\DYMO Label Software\MDYMOBarcode.dll
DateTime=2018-04-23T17:08:50.1456872Z
DYMO.DLS.Printing.Host.exe Information: 0 : Utils.CreateLabelPrintParams(): printParams == null, creating default printParams based on printer type
DateTime=2018-04-23T17:08:50.1547276Z
Status for job sent to printer DYMO LabelWriter 450 Turbo i False
DYMO.DLS.Printing.Host.exe Information: 0 : CheckServiceStatus
DateTime=2018-04-23T17:08:51.3098746Z
DYMO.DLS.Printing.Host.exe Information: 0 : GetPrinters
DateTime=2018-04-23T17:08:51.3269198Z
I tried updating to DLS8Setup.8.7.exe but this did not help.
I broke out Procmon and got to the bottom of this.
It appears to be due to the Dymo Label Service querying 128.30.52.100 (hans-moleman.w3.org) every time it was fed a label to validate its schema. We were not being rate limited by this service until today.
Setting an outbound firewall rule against this IP address for the DLS service executable fixed the issue.
We just ran into this as well. Apparently the Dymo print service is trying to validate the generated xml against an xsd file. That file is not cached, so the print service is hitting w3.org to download it. Some time recently w3.org stopped responding to this request, making the xml validation slow as the request times out. So this is unrelated to any Windows update, update to the Dymo print service, or update to any browser.
If you run this command in Windows power shell as an administrator (and the path to your service is the same as ours), it will block the call to w3.org, causing it to fail fast instead of slow and move on to printing.
New-NetFirewallRule -DisplayName "dymo-xsd-exclude" -Direction Outbound -Action Block -Program "C:\Program Files (x86)\Dymo\DYMO Label Software\DYMO.DLS.Printing.Host.exe" -RemoteAddress 128.30.52.100
This is a short term solution. The correct solution is for Dymo to update their print service to include the xsd instead of calling across the internet for it.
I have been experiencing this issue too, here is the link to the Dymo Developers blog and the recommended solutions.
http://developers.dymo.com/2018/04/24/recent-issues-with-slow-printing/
The 2 solutions recommended on this blog are:
1) Prevent connections to 128.30.52.100 (http://www.w3.org/1998/XMLSchema)
2) Use the windows defender firewall to prevent DYMO.DLS.Printing.Host.exe from making outbound connections.
FYI. Dymo has a fix posted. They released version 8.7.1 which fixes the slowness issues. It can be downloaded from the developers site:
http://developers.dymo.com/2018/04/24/recent-issues-with-slow-printing/
Related
I have migrated an application that was running on Windows Server 2008 to one on Windows Server 2012.
It is a desktop application that makes many calls to the server's .asp scripts, and from them calls are made to stored procedures in SQL Server.
The program that makes the calls from the client computer, is a DLL made in Delphi 7.
This mount was working properly on the computer on Windows Server 2008.
But now I have come to the conclusion that scrips are not executed in .asp since I do not receive a response from the server, although I see in the .log file they are called and with the correct parameters.
The following lines are from the .log file
2018-11-27 15:51:20 nn.nnn.nnn.223 GET /soporte/lnk_mnto.asp COD=MFM0010010LRN&APP=MF&cachedisable=FNFAJDNHFIDLELA 80 - nn.nnn.nnn.nnn HTTP/1.0 Mozilla/4.0+(compatible;+Synapse) - www.ikutgroup.com 301 0 0 569 205 62
2018-11-27 15:52:36 nn.nnn.nn.223 GET /soporte/lnk_mnto.asp COD=MNF5369168SB7&APP=MN&cachedisable=IHOLGLANIEKMBJE 80 - 89.128.30.175 HTTP/1.0 Mozilla/4.0+(compatible;+Synapse) - www.ikutgroup.com 301 0 0 569 205 46
As you can see, COD and APP are the parameters that the script lnk_mnto.asp needs, and the call from the Delphi DLL is registered in the log file, but the DLL doesn't receive an answer.
But, if I call the asp script directly from the browser through this call:
http://xxxxxxxx.com/soporte/lnk_mnto.asp?COD=MNF5369168SB7&APP=MN&cachedisable=HNIKNFNMEJMFBDH
I receive the correct answer.
I know that in the first case, the script is not executed, because I added in the first instructions of it the recording of a line in the database, and this does not occur. Instead, when the script is called from the browser, the row is recorded in the table of the database.
I think it's a problem of permissions, but I have no idea what I should look at to correct it.
Do you have any ideas that allow me to try to solve my problem?
No. Is the dll from the Client computer who call to the .asp script in the Server.
But in the end I made a new test program in Delphi, copying the instructions that call the script in .ASP and when I ran it I saw that it returned an error of the type:
<.head><.title>Document Moved<./title><./head>
<.body><.h1>Object Moved<./h1>This document may be found <.a HREF="http://myweb.com/soporte/lnk_mnto?COD=MNF873455SB7&APP=MN&cachedisable=GNDECGBLJBFHBHA">here<./a>
Then I looked for information on the web about this error message and I found the following page that has solved my problem
https://network.convergenceservices.in/forum/68-plesk-panel-hosting/3711-document-moved-or-object-moved-error.html
In short, it says that in the Plesk configuration of the page, you have to put 'none' to the question: 'Preferred domain'.
Login into the plesk control Panel
Click on Websites & Domains
Click on Hosting Settings
Select the “None” drop down list box from “Preferred domain”
Click on OK
Now my problem is solved.
Thank you very much to all.
I have been trying to figure out why Wake On Lan works for Right Click Tools, but not for SCCM Scheduled Deployments.
In the wolmgr.log file I found this happening every five seconds: "Failed to get WOL inbox on AMT Proxy component. Wait 5 seconds... SMS_WAKEONLAN_MANAGER 9/19/2018 11:32:24 AM 480 (0x01E0)".
In the wolcmgr.log file I don't see any errors except this happening about four times a day, which I think is referring to the endless errors shown in the other log file: "CBaseCounter::Initialize - Registered performance counter "Total Number of Packets failed" SMS_WAKEONLAN_COMMUNICATION_MANAGER 9/19/2018 2:01:59 AM 9496 (0x2518)"
I have tried to look up these error messages and haven't found anything to help me get this resolved.
I have tried various ports, including the default (9) and 12287, currently it is on 7. We are being told to use subnet directed broadcasts by our network team due to some limitations with our Cisco network configuration.
I do have a SQL Server Agent (ADK) service that was disabled. I enabled it and it starts but turns off immediately. I don't know if that is related at all. I did have some deployment issues with Windows 7 drivers giving errors during the task sequence, even though they were installing. So I installed a Windows 8.1 ADK after seeing an article about bugs with the latest Win10 ADK and SCCM Task Sequences installing Win7 drivers. I've since then installed Win10 1703 ADK, which works on one of my other SCCM servers on Win7 deployments fine, and I was having this WOL problem before installing 1703 ADK.
Under Administration > System Status > Site Status > Management Point, when I show messages I see these:
*Description Severity
Type Site code
Date / Time System
Component Message ID
Thread ID Process ID
The Wake On LAN component has failed to read the site control file settings. Possible cause: The information is not yet available. Solution: The component is waiting for the information to become available and will retry obtaining the information at its next interval. Error
Milestone CML
9/20/2018 12:47:56 PM SMS_WAKEONLAN_MANAGER
6500 3384
3988
Description Severity
Type Site code
Date / Time System
Component Message ID
Thread ID Process ID
The Wake On LAN component has failed to read the site control file settings. Possible cause: The information is not yet available. Solution: The component is waiting for the information to become available and will retry obtaining the information at its next interval. Error
Milestone CML
9/20/2018 9:39:03 AM SMS_WAKEONLAN_MANAGER
6500 2924
2636*
ADK SQL Server Agent
SCCM WOL configuration
WOL ports
wolmgr.log file screen shot
RightClickTools WOL Configuration
Yesterday our extracts failed to refresh with the following message (image extract_error):
Failure: Failed 1 time. Sign in failed.
Resolution Details: Check the Data Connection page for necessary updates to an access token or embedded credentials.
I verified that all our passwords were unchanged and test connections which were successful.
The tableau dashboards now give an error message saying:
HTTP 404:
Unable to connect to the server "localhost". Check that the server is running and that you have access privileges to the requested database. (image tableau_error)
Further, when I opened the Server Status page, I saw that our one of our two Vizql, backgrounder and data servers were down. We have two of each and only one of them is active for all three of them. (image server_status)
So, I decided to remote desktop into the server and run the tabadmin status -v command and strangely it is showing that all processes are running. (image tabadmin_status)
Finally, I opened a case with Tableau Customer Portal and letting them know about this issue (they asked me send them the log.zip file) but the mean time I was trying to problem solve this issue. Any help would be really appreciated.
After trying a lot of things, one process seemed to work.
Stopped the tableau server
Configured it to run 1 Vizql server process instead of 2
Started the server again
Finally, it worked. The status page now shows all the processes are active.
Hopefully, this helps someone who is facing a similar problem.
This may be caused by a firewall issue. Since tabadmin status -v returned all as "running" the cluster is healthy and this is a false alert. The firewall rules could be allowing just the first port and not the entire range (see https://onlinehelp.tableau.com/current/server/en-us/ports.htm) to respond to requests from the application server to build that fancy table with the green and red boxes.
The firewall can be reverted/altered behind the scenes for a number of reasons, usually windows updates or regular group policy synchronization.
Try disabling the windows firewall (https://www.faqforge.com/windows-server-2016/turn-off-firewall-windows-server-2016/), or add an inbound rule allowing access to all ports if your org policy doesn't allow you to actually turn it off. (Follow the steps here, except use "All Local Ports" instead of "Specific Local Ports" https://www.parallels.com/blogs/ras/configuring-windows-server-firewall-for-parallels-ras/)
I had a similar problem and followed these similar steps that Sravee mentioned above to bring the all processes back to active.
Stopped the server
Change the configuration for VizQL server from 2 to 1
Started the server
Enter the licence key (else the server status page will show unlicensed error)
Note: This does not bring the site back but this step is for 'tricking' VizQL server
Stopped the server again
Change the VizQL configuration from 1 to 2 now.
Start the server
Enter the license key
This steps did bring back the server back to active for us. Posting to see if this helps who faces the same problem. Thank you so much.
I am trying to do a load tests for the call forwarding B2BUA application sample on MSS 2.00 (Sip Servlet).
I am doing a 80 Caps on 4 Tomcat Instances on linux Redhat 2.6
The problem I am facing is that the 100 For the UAC invite is not send immediatly once recieved on MSS,
It is sent only one the 100 from the UAS returns it.
I managed to find a case on JBOSS which uses the following configuration flag
http://code.google.com/p/mobicents/source/browse/trunk/servers/sip-servlets/sip-servlets-test-suite/sipp-scenarios/performance/jboss-5-setup/mss-sip-stack-jboss.properties?r=14623
it appears to be some kind of an old bug fix
http://code.google.com/p/mobicents/issues/detail?id=1689
However, I tried to put the following entries in the mss-sip-stack.properties
org.mobicents.ext.java.sip.TRANSACTION_FACTORY=org.mobicents.ext.javax.sip.MobicentsTransactionFactory
org.mobicents.ext.java.sip.SIP_PROVIDER_FACTORY=org.mobicents.ext.javax.sip.MobicentsSipProviderFactory
org.mobicents.ext.java.sip.SEND_TRYING_RIGHT_AWAY=true
but it didn't made a change
I tried to dig into the code and found out this:
The flag is defined in the following interface
SipStackExtension
as well as the other factories
However, The only available impelemtation was the ABSTRACT class ClusteredSipStackImpl
So what should I do inorder to enable this flag on the above configuration?
I made the test on an amd64 blade (12 cores),
I tried both 32 Bit and 64 Bit, the result was the same.
The flag was not usable on Tomcat, only JBoss, that is now fixed in http://code.google.com/p/sipservlets/issues/detail?id=138 and will be available in our next release 2.0.0.FINAL
Thanks
Jean
I continue to get this error message "Cannot uninstall Language Pack 0 because it is not deployed" when running the uninstall-spsolution cmdlet. I've attempted a number of alternate syntaxes to no avail. (tried add -language 1033 for example) I see a few other similar issues on the web, but nothing specifically addressing my issue. I know the solution exists. not sure why the Language Pack issue is arising. (by the way...i can see my solution using Sharepoint manager 2010). I've tried a number of anyway, any help would be appreciated. thanks.
(Note: was unable to upload image of error from powershell command shell due to site restriction).
I'm also seeing this error in one of our farms when I run the Update-SPSolution commandlet. Recently, we updated the farm with foundation and server Service Pack 1, the associated server language packs and the June Cumulative update. By chance, is this the patch level of your farm? Interestingly, I have no trouble running Update-SPSolution in another farm patched to the same level. The bottom-line is that I don't think this is limited to Uninstall-SPSolution or Update-SPSolution.
I just resolved the issue by doing the following:
Checked the solution store and saw that the solution I was updating was not deployed
I attempted to deploy the solution and saw that it was stuck in the deployment stage
From services.msc I stopped and restarted the SharePoint 2010 Timer service and the SharePoint 2010 Administration service. I don't normally stop and start SharePoint services from Services, but that seemed to do the trick. I also don't know whether it's necessary to recycle both of these services.
I then returned to the command line and was able to successfully update the solution.
Please let me know if this works for you.
While I like the answer above and I think it would work some of the time, in my case I had to remove the Errored out WSP from the solution store and then re-add it and then install/deploy it again. After that my updates were working fine again.
I had the same issue, I opened the manage solutions in central admin and there was an error message next to my solution. The error message was actually helpful, it directed me to solve the issue. I have added -force while installing the solution using power shell command then it worked fine.
After that I deactivated and reactivated the feature just in case.
I've got the same problem and restarting the services was not enough for me.
Then, I solved doing:
Retract and then Remove of the wsp from: Central Administration–>System Settings–> Manage farm solutions.
Then, from Powershell, I have canceled the Features with null scope (which were preventing me to install again the package succesfully):
Get-SPFeature | ? { $_.Scope -eq $null }
$feature = Get-SPFeature | ? { $_.Scope -eq $null }
$feature.Delete()
And at the end I have installed again the wsp:
Add-SPSolution -LiteralPath Path
Install-SPSolution -Identity Name.wsp -WebApplication WebApplicationPath –GACDeployment
Then it worked :)
Update: I've just got this problem again, but this time there weren't features with null scope, so it has been enough just to add -Force while installing the wsp.
I had the same issue and after redeploying solution it's gone.