We have a job which is located in Windows server and this job is responsible for sending files to a Linux box through WinSCP utility.
We observed that file transfer process failing due to the connection error on an average every alternate day.
We are getting below error message in logs:
Upload of file 'xxx_20190103031754.csv' was successful, but error occurred while setting the permissions and/or timestamp.
If the problem persists, turn off setting permissions or preserving timestamp.
Alternatively you can turn on 'Ignore permission errors' option.
General failure (server should provide error description).
In order to fix the issue I googled to set -rawtransfersettings for put command
open sftp://xxx#xxx.example.com/ -hostkey="ssh-rsa 1024 xx:xx:xx:xx:xx:xx" -timeout=60 -rawsettings SendBuf=0 SshSimple=1
put -rawtransfersettings IgnorePermErrors=0 PreserveTimeDirs=0 "E:\Final\XXX_ASSIGNMENT_20190416200819.csv" "/<Linux Box Folder Name>/"
But I am getting below error
Authenticating with pre-entered password.
Authenticated.
Starting the session...
Session started.
Active session: [1] xxx#xxx.com
Unknown switch 'rawtransfersettings'.
The -rawtransfersettings switch is supported by the latest WinSCP 5.15 only. You are probably using an older version of WinSCP.
Also, if your goal was to to enable "Ignore permission errors", you need IgnorePermErrors=1 (0 is the default value).
Side notes: PreserveTimeDirs is not related to your problem and is 0 by default anyway. So you can remove that. And the double slash is suspicious, you should probably use one only.
This should do:
put -rawtransfersettings IgnorePermErrors=1 "E:\Final\XXX_ASSIGNMENT_20190416200819.csv" "/"
But if your server actually does not support preserving timestamps, then you should rather use -nopreversetime switch. See the documentation for the error message:
When using scripting, add -nopreservetime and -nopermissions switches to put command.
Related
I have a BizTalk 2013r2 Standard Edition application server with CU7 installed. The BizTalk databases are hosted on a separate Sql Server 2014 server. This setup has been working fine for many months - until today! A colleague used the BizTalk admin console to make a change to the address BizTalk uses to the reach the SMTP server, by selecting Platform Settings\Adapters\SMTP\\properties.
After making this change, on attempting to refresh the BizTalk Admin Console, the following error is displayed:
From what I've googled, it seems this may be due to some corruption in the SSO database. I have a backup of the SSO database, and a backup of the SSO key along with the password. Before restoring the backup of the SSO database, I wanted to check that I would be able to restore the key, so I ran ssoconfig -restoreSecret from the command line. I was prompted to enter the password. If I intentionally enter the wrong password then it tells me the password is incorrect. However, if I enter the correct password then it displays the message "BAD DATA".
Although the BizTalk admin console is currently unusable, thankfully the BizTalk host instance continue to run and messages are being processed as expected.
Can anyone please suggest why I'm getting the "BAD DATA" message, or perhaps a work-around in order to solve the problem?
I had this problem again and blogged about it at BizTalk WinMgt error solution. As Colin says the hard part is identifying the corrupt handler. It is probably the SMTP send handler but you should check this using WBEMTEST first. I found this link helpful on using WBEMTest. The parameter is incorrect (WinMgt)" error when refreshing the BizTalk Group in BizTalk Administration Console
In my case a quick fix to bring the BizTalk Administration Console back to life was to hack the database. N.B. This probably won't be supported by MS. In my case it was the FTP send handler that screwed up. So I ran
USE [BizTalkMgmtDb]
GO
DECLARE #return_value int
EXEC #return_value = [dbo].[adm_SendHandler2_Delete]
#AdapterName = N'FTP',
#HostName = N'Sending32'
SELECT 'Return Value' = #return_value
GO
At this point the BizTalk Administration console came back to life. In my case it worked because I was creating a new handler but in your case you just edited it. It will take all your SMTP handling out.
I then fixed the corruption using the BizTalk Administration console.
In my case I had to set every FTP receive and send adapter temporarily to a FILE adapter.
I then deleted the FTP adapter and then re-added it. Finally I reset the all the change receive and send location from FILE back to FTP.
This was all very scary on a live system.
Finally I believe that this is bug in BizTalk 2013 R2 because I've seen it happen on 2 systems and now I have heard that the same thing happened to you.
The WinMgt error happens when one of the Adapters setting has gotten itself corrupted. See WinMgt error when refreshing Group Hub
Removing and re-adding the adapter to the host usually fixes it. The trick of course is identifying which Adapter / Host, I would start with the SMTP adapter in your case.
I am trying to get the Zumero for SQL Server working and I cannot get past running the test client. I get the below error
Connection string in web.config is
<settings temp_directory="C:\ProgramData\Zumero\ZSS Server\temp\"
odbc_connection_string="DSN=krishna;User Id=syncadmin;Password=syncadmin;"
license_key="<removed>" />
The description for Event ID 1 from source Zumero cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
Error -1 (mssql): {"diag":[{"SQL_DIAG_MESSAGE_TEXT":"[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot open database \"ZumeroTest\" requested by the login. The login failed.","SQL_DIAG_NATIVE":4060,"SQL_DIAG_SQLSTATE":"42000"},{"SQL_DIAG_MESSAGE_TEXT":"[Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr failed","SQL_DIAG_NATIVE":0,"SQL_DIAG_SQLSTATE":"IM006"},{"SQL_DIAG_MESSAGE_TEXT":"[Microsoft][ODBC SQL Server Driver]Invalid connection string attribute","SQL_DIAG_NATIVE":0,"SQL_DIAG_SQLSTATE":"01S00"}],"SQLRETURN":-1}
..\..\..\src\core\sg\sg_mssql.c:344
..\..\..\src\core\sg\sg_mssql.c:384
..\..\..\src\core\server\zum_db_mssql.c:2896
..\..\..\src\core\server\zum_respond.c:4454
..\..\..\src\servers\iis\main.cpp:1211
The publisher has been disabled and its resource is not avaiable. This usually occurs when the publisher is in the process of being uninstalled or upgraded
Either the SQL Server user doesn't have rights or the database doesn't exist.
You can use a DSN, but for troubleshooting purposes I recommend putting the connection details directly in the connection string for now. Once it's working you can migrate the settings back to a DSN if you like.
Looks like you're using SQL Server authentication. So the odbc_connection_string value should look like this:
Driver={SQL Server Native Client 11.0};Database={database};Server={server.ad.domain.com};UID={sql_server_user};PWD={password};
The database must exist and the user specified must have appropriate read/write access to it.
(If you're setting minimum necessary permissions, you'll also want to make sure the user has VIEW SERVER STATE rights, as described here.)
While unrelated to your invalid connection string problem, the messages about The description for Event ID 1 [...] and The publisher has been disabled [...] indicate that ZSS hasn't been correctly registered with the Windows Event Viewer. Did you install the server by hand (from the .zip file) or using the installer?
You can fix those messages using the following command (which probably requires an admin prompt):
wevtutil im "PATH\TO\events.man" /rf:"PATH\TO\zumero_server.dll" /mf:"PATH\TO\zumero_server.dll"
where PATH\TO is the path where you extracted those files from the .zip. If you used the installer then they should be located at: %PROGRAMFILES%\Zumero\ZSS Server
If you installed manually from the .zip then it's worth noting that the instructions had a subtle typo in that command which would cause it to fail. That typo has been fixed in the past few days, but it may have caught you during your installation and caused this issue.
I had successfully configured Oracle webcenter on some of my VM.
To access it from my local machine I did some changes in firewell setting.
Then after the home page is not accessible and i get 404 error.
i.e.,
http://:8080/cs/REST/ is not accessible where as some other REST URLs are accessible such as :
http://:8080/cs/REST/types/
http://:8080/cs/REST/sites/
http://:8080/cs/REST/sites/FirstSiteII/
I think something wrong with my asset type configuration. How to resolve?
Any idea would work for me.
You should be looking at log files which can be generated by the content server.
The “View Server Output” menu provides access to the most recent server output logs.
Iirc, you can set different levels of tracing and you should select the option(s) which are relevant to you issue - otherwise the trace log file will generate a huge amount of text - much of it irrelevant to you & making it particularly hard to read.
The log file is timestamped but it would be better served if you have a single-user make a single attempt to land on your URL(s).
Server output also contains tracing output if enabled. Tracing is typically enabled while
debugging errors. If server output is being captured in a file, the file could grow large if tracing options are enabled. Consider disabling all server tracing options (especially if “verbose” option is checked), to keep server output file size in check.
I don't believe that there's anything served at /cs/REST/ - what would you expect to see?
I'm trying to enable MSMQ on my development computer (running Windows 7).
I go to turn windows features on or off -> Microsoft Message Queue (MSMQ) Server Core -> Check MSMQ Active Directory Domain Services Integration AND MSMQ HTTP Support.
When I click OK, I get the error "An Error has occurred. Not all of the features were successfully changed." -> Click OK -> "You must restart your computer to apply these changes".
I've clicked Restart Now and Restart later and no matter what, same issue every time.
If I selected Restart later and go into Services...I see Message Queuing (stopped), and if I try to start the service, I get the error "Windows could not start the Message Queuing service on Local Computer. Error 0x80070005: Access denied."
I checked my privileges and I am an Admin on the machine. Just to be safe, I even logged into the machine as the actual Administrator. Same scenario.
Furthermore, when I go into the Event Viewer, I check the Application logs. I have an error with MSMQ as the Source. EventID: 2076, Error: The logger files cannot be initialized. The file QMLog in the Msmq\Storage folder is corrupted or absent. Error 0x80070005: Access denied.
If I check the System Logs, I see another error with the source being Service Control manager. Error eventId: 7023, Error: The Message Queuing service terminated with the following error: %%-2147024891
When I look up the error codes on Microsoft, there is NOTHING.
I had something like this - not sure how it came about as I always had AD integration turned ON for my MSMQ (as I needed it) but somewhere along the line, it got turned off and I couldn't turn it back on again via Control Panel - I would get the error behaviour (and restart!) that the OP describes. To fix it, I accessed my machine via the AD services manager app on one of our domain servers and deleted the "msmq" object that was under it.
I restarted my local MSMQ service on my machine AND rebooted (not sure which or both was required) and then when I checked my local registry entries, it indicated I was correctly running in AD mode once again. Everything started to work again after that.
This link was helpful in giving me the right direction to go in: Technet MSMQ delete stale objects article
On Centos 6.2, trying to get the kernel log redirected to the serial console, I came across an issue where agetty seems to be respawning every few keypresses.
That is, I get a login prompt in the middle of typing (after logging in).
In order to investigate the issue further, I'm looking for the location of agetty logs, but to no avail. Where and how can I see log messages for respawned agetty process?
The "diagnostics" section of the "agetty" command manpage states:
Depending on how the program was configured, all diagnostics are written to
the console device or reported via the syslog(3) facility. Error messages are
produced if the port argument does not specify a terminal device; if there is
no utmp entry for the current process (System V only); and so on.
The syslog facility by default writes the "/var/log/messages" file, but it can be configured to write another file by editing its configuration file "/etc/syslog.conf".
Finally, if the error you get is "respawning too fast", you should check your "/etc/inittab" file, as described here.