BITS credential problem - download

I have a service to download file using credential domain\user but get this error :
ErrorCode [-2147023582] 80070522
Description [A required privilege is not held by the client.]
ErrorContext [RemoteFileError]
at Windows Server 2003 64 bits
I'm setting credential so :
bc.AuthenticationScheme = AuthenticationScheme.Negotiate;
bc.AuthenticationTarget = AuthenticationTarget.Server;
The user has full access rights on source and destination folders.
Using SharpBits library.
It seems to be missing some right of access yet. Any suggestions?
[EDIT]
It seems that there is some failure in resource access provided by the BITS service.
Still investigating.
[EDIT]
Investigating the rights to use BITS.
-with the command "sc sdshow bits" I get this output on the environment where it works :
D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)
(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
-where the copy does not work :
D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)
(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)
(A;;CR;;;AU)
(A;;CCLCSWRPWPDTLOCRRC;;;PU)
S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

The solution : added the user "NT AUTHORITY\NETWORK" permissions to read at folders in all remote hosts.
That's it.

Related

How to install tnsping?

How do I have to install tnsping?
I tried to install oracle-instantclient12.1-basic-12.1.0.2.0-1.x86_64.rpm and I'm able to use some client commands but nog tnsping.
Oracle Instance Client does not include tsnping application. You must run "Oracle Universal Installer" and enable the option for it.
I don't' remember exactly which option you have to set, either it was "Oracle Database Utilities" or "Oracle Net"
Also see McTnsping [link broken] "a Windows stand-alone program which requires no Oracle client". It's portable and doesn't need to be installed.
Usage 1: McTnsping.exe { <tns entry> | <host>:<port> } [<count>]
<tns entry> the net service name in the tnsnames.ora file.
<host>:<port> server name or IP and port (mandatory)
<count> number of times to check target, default is 1.
If whoever will reach the place like me... This is what worked for me:
Instant client Version 12.2.0.1 + sqlplus + tnsping (copied from another server of the same version)
Directory structure and env (as in bash profile):
export ORACLE_BASE=/opt/oracle
export ORACLE_HOME=${ORACLE_BASE}/instant_client122
export PATH=$ORACLE_HOME:$PATH
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME #since all binaries are in $ORACLE_HOME - no bin or lib are present
export TNS_ADMIN=$ORACLE_HOME/network/admin
copy from another server to target:
'tnsping' to $ORACLE_HOME
'$ORACLE_HOME/network/mesg/tnsus.msb' to $ORACLE_HOME/network/mesg
Then put proper values to $TNS_ADMIN/tnsnames.ora and load env variables. After this it should be able to perform 'tnsping' and show proper message as a response.
Here's what I did to copy tnsping over to another machine. In my case, the oracle client is installed at C:\Oracle\product\12.1.0\client_1.
This assumes there's already an Instant Client or similar installed on the destination machine; and that the oracle path and registry keys are set.
(1) Copy tnsping.exe from the source to the destination machine, into client_1\bin.
(2) Copy the following files from client_1\bin to client_1\bin:
oraasmclnt12.dll
oracell12.dll
oraclient12.dll
oraclsce12.dll
oracommon12.dll
oracore12.dll
orageneric12.dll
orahasgen12.dll
oraldapclnt12.dll
oran12.dll
orancds12.dll
orancrypt12.dll
oranhost12.dll
oranl12.dll
oranldap12.dll
oranls12.dll
oranro12.dll
orantcp12.dll
orantns12.dll
oraocr12.dll
oraocrb12.dll
oraocrutl12.dll
oraplp12.dll
orapls12.dll
ORASLAX12.DLL
orasnls12.dll
oraunls12.dll
orauts.dll
oravsn12.dll
oraxml12.dll
orazt12.dll
oraztkg12.dll
This should be about 84.6 MB.
(3) In the client_1 on the destination machine, make a backup of the following files:
oci.dll
orannzsbb12.dll
oraons.dll
orasql12.dll
orawsec12.dll
Now on the source machine, find those files in client_1\bin and copy them to client_1\ (no bin) on the destination machine, overwriting the existing files. (Note: oci.dll is ~330 kb smaller, orasql12.dll is ~300 kb smaller. I'm not sure what's lost, hence the backup).
(4) On the destination machine, create the directory mesg in client_1\Network. Now copy the following file from the source to the destination:
client_1\Network\mesg\tnsus.msb
(5) Open up regedit. Create the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\KEY_OraClient12Home1_32bit
(From another machine, it looks like the x64 version is named HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\KEY_OraClient12Home1, but the tnsping program I'm using says it's 64 bit, so ...)
Under the key, create a string named ORACLE_HOME with the value C:\Oracle\product\12.1.0\client_1.
You should be done now ($$$ = redacted):
C:\Users\$$$>tnsping $$$
TNS Ping Utility for 64-bit Windows: Version 12.1.0.2.0 - Production on 03-APR-2
019 08:47:37
Copyright (c) 1997, 2014, Oracle. All rights reserved.
Used parameter files:
C:\Oracle\product\12.1.0\client_1\network\admin\sqlnet.ora
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = $$$)(PORT = $$$))) (CONNECT_DATA = (SERVICE_NAME = $$$
$$$) (SERVER = DEDICATED)))
OK (30 msec)
Troubleshooting
Here's the process I followed, sharing for when these steps invariably fail to work on a later version.
First off, I just copied the tnsping.exe over.
I didn't haphazardly pick the above dlls, as far as I can tell everyone is required. I ran the exe, and it would popup an error, I would copy the dll over and try again:
After a few dlls, you'll run into a different kind of error:
If that happens, fire up process monitor and put a filter in for the ProcessName to contain tnsping and try to run the program again. You should see something like the following. The main thing to notice is that it tries to load (in this example) orawsec12.dll, which succeeds, but then it continues to try to load the dll looking in different paths, and then at the end it triggers werfault and the program ends. I guess it realizes there's some kind of version mismatch and keeps looking for the right version.
The missing registry key will show up like the following in process monitor (operation RegOpenKey, result NAME NOT FOUND):
If the tnsus.msb file is missing, you should see something like the following in process monitor (operation CreateFile, result NAME NOT FOUND):

Why/how are Registry Entries Hidden in Regedit but visible in PowerShell?

I'm working with a new property schema, and have been in the habit of checking the registry when I register or unregister a new version. One of the primary places to check this is HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\PROPERTYSYSTEM\PROPERTYSCHEMA.
Interestingly, I occasionally lose access to this registry location in Regedit. I see see this (note the absence of PropertySchema):
I know the schemas are still registered, because I can use the prop.exe tool and propschema SDK sample application to describe them. The properties are available in Windows Explorer and in Search.
Also, I can use PowerShell to list the contents of this hive:
C:\Users\carlton> cd hklm:
HKLM:\>
C:\Users\carlton> cd hklm:
HKLM:\> cd SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\PROPERTYSYSTEM\PROPERTYSCHEMA
HKLM:\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\PROPERTYSYSTEM\PROPERTYSCHEMA> dir
Hive: HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\PROPERTYSYSTEM\PROPERTYSCHEMA
Name Property
---- --------
0000 (default) : C:\Program Files\Internet Explorer\ie9props.propdesc
SchemaId : {D9B5ABA1-5E8A-4902-B6A1-50B3C0311C2E}
URI : ie9props.propdesc
CompactURI : 5376bae4b39f43768806afcb6b8ff5464bf9c989d1a819c6e6d99ba1e8ce2512
0001 (default) : C:\Program Files\Microsoft Office\Office14\Custom.propdesc
SchemaId : {537AAAB1-1D85-48DC-A99E-16EB8C309FE5}
URI : custom.propdesc
CompactURI : 2e3be58e5cbbc0da093956b46a3905f11cf0f5bbf11987a8619e25f7261ee8be
0002 (default) : C:\apps\MSOffice\Office14\VisioCustom.propdesc
SchemaId : {18503526-0466-4942-AC6E-41C1D380EABA}
URI : visiocustom.propdesc
...
Anyway, I don't understand how this happens, and whether I should be worried about it. Exporting this key from a colleague's machine and re-importing it can temporarily help, as it will show keys in Regedit that were hidden/missing (even if they weren't on my colleague's machine).
I'm in the Administrators group, running Windows 7 SP1.
The 32bit program data on 64bit systems available in 'Wow6432Node' folder of the registry (in above case 'SOFTWARE\Wow6432Node\MICROSOFT\WINDOWS...'). This is transparent to the applications, hence you can read data from applications but you don't see that in Regedit.
Harry Johnston's intuition was correct. I re-ran regedit from a command line with the path c:\windows\regedit, and I once again see what I expected under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\PropertySystem\PropertySchema. I could've sworn it wasn't showing it either, but it's working now, apparently.
I confirmed as much by exporting the parent key (PropertySystem) from the 64-bit and 32-bit regedit's and running Beyond Compare. The propdesc files are verily not there in the 32-bit version.
See 32-bit and 64-bit Application Data in the Registry (MSDN)

Active component cant create obj error

I am trying to script for file transferring ,its works fine when am clicking manually the script.But when am trying to run as Scheduling task i receiving an error "Active component cant create obj",i don't know what went wrong in my script?
For your reference i have my script below.
Dim Mysite
Set MySite = CreateObject("CuteFTPPro.TEConnection")
Set fso = CreateObject("Scripting.FileSystemObject")
MySite.Protocol = "FTP"
MySite.Host = "www.domainname.com"
MySite.Login = "xxxxx"
MySite.Password = "xxx"
MySite.UseProxy = "BOTH"
MySite.Connect
MySite.UploadAsync "C:\sampletest\abc.flv"
MySite.RemoteFolder = "/test/abc.flv"
MySite.Disconnect
MySite.Close
FYI my machine is windows 2008 64 bit system
In most cases issue raised by one of the following:
User does not have proper permission to run a scheduler
User does not have proper access to the folders/files listed
Application you are using running under different permission set for logged in user and system account which is used by Task Scheduler.
OS is not recognizing what application version it have to execute 32 or 64 bit when attempt to execute scheduled task.
Take a closer look on those situations, make adjustments and it will work.

Automap library issue in Windows7 (with R 3.0.1)

I installed sp and automap libraries to my R 3.0.1 64-bit under Windows 7 (via install.packages command). Installation of them did not display any error and library(sp) works fine however when I try to execute library(automap) I get the following error:
> library(automap)
Error in gzfile(file, "rb") : cannot open the connection
In addition: Warning messages:
1: In read.dcf(file.path(p, "DESCRIPTION"), c("Package", "Version")) :
cannot open compressed file 'C:/Program Files/R/R-3.0.1/library/sp/DESCRIPTION', probable reason 'No such file or directory'
2: In gzfile(file, "rb") :
cannot open compressed file '', probable reason 'Invalid argument'
I looked from the path and indeed there is no DESCRIPTION file (or folder) in that path. However there is just libs folder under which folder x64 and inside it file sp.dll
Any idea what could cause this?
I would definitely try to run R as administrator, both for installing the packages and loading them. This could solve your problem.
This probably has to do with file permissions. When you install the packages as admin in a location where only admin can read/write, running R as a normal user means you do not have the file permissions needed to load the package. Running R as admin will solve this, as admin does have the correct permissions.
Alternatively, you could install your R packages in a location where a normal user has read/write persmissions, e.g. C:/Users/UserName (or something like that, I do not have my windows machine accesible right now).

Windows 8 driver install and catalog/signature validation

I can't get windows 8 (release preview) to accept either the inf2cat or makecat approach described as solutions to the question at
What changed in the driver signature requirements for Windows 8?
unless I disable validation.
I am not signing these with any certificates at this point, just trying to get past the errors preventing the drivers from installing at all.
Windows 8 gives me a very nondescript error:
"A problem was encountered while attempting to add the driver to the store."
Looking in the event logs, there is nothing of use; only an informational entry from "Windows Error Reporting" indicating a PnPdriverimporterror.
When i use my original files with the cab files that don't match the inf, I get the error everyone else is listing:
The hash for the file is not present in the specified catalog file.
I have one .inf file that i need to generate a .cat for.
Perhaps I am doing something wrong. Ideas??
INF2CAT Approach
c:\win_xp_vista32_64>inf2cat /driver:"." /os:XP_X86,XP_x64,Vista_X86,Vista_x64,7_X86,7_X64,8_X86,8_X64
.......................
Signability test complete.
Errors:
None
Warnings:
22.9.10: usbser.sys in [drivercopyfiles.nt] is missing from [SourceDisksFiles] s
ection in \mchpcdc.inf; ok if file source is provided via LayoutFile in [Version
].
22.9.10: %driverfilename%.sys in [drivercopyfiles.ntamd64] is missing from [Sour
ceDisksFiles] section in \mchpcdc.inf; ok if file source is provided via LayoutF
ile in [Version].
Catalog generation complete.
c:\win_xp_vista32_64\mchpcdc.cat
MAKECAT approach
--- start of catalog.cdf file---
[CatalogHeader]
Name=mchpcdc.cat
ResultDir=.\
[CatalogFiles]
<hash>mchpcdc=.\mchpcdc.inf
---end of .cdf file ---
c:\win_xp_vista32_64>makecat catalog.cdf
These same files, w/ the cat from either approach install just fine in Windows 7.
I think this problem is to do with "windows driver signing enforcement". You can resolve this by disabling this option. Go through with below link:
http://tivadj-tech.blogspot.in/2012/09/certificate-check-error-when-installing.html
I just tested this on Windows 10 and 8 PRO now, to get this right, follow these steps:
1) From your Start menu, locate your DDK's "x64 Checked Build Environment" i.e. the custom DOS build screen. Right-click, run-as administrator...
2) Compile your source with the Build tools etc.
3) Go into your compiled code, and then create your test-certificate (you don't need to purchase one just yet, use your self-signed one created with the line below):
makecert -r -pe -ss PrivateCertStore -n CN=newhex.com(Test) NewhexTest.cer
The above means your certificate is called "newhex.com(Test)" and the generated file is "NewhexTest.cer"
4) Create / Edit your .CDF file which contains items about what your CAT file's contents.
5) Create your CAT file by executing:
makecat -v MyCDF.CDF
This should generate an un-signed CAT file that includes all files specified by your CDF.
6) Sign your CAT file as follows:
Signtool sign /v /s PrivateCertStore /n newhex.com(test) /t http://timestamp.verisign.com/scripts/timestamp.dll MyDriverWhatever.cat
This should result in a CAT file that is signed, but don't just install it, because your Windows can't trust Newhex's cert since it's not in the keystore, to fix this do:
7) Add your certificate to your private Key Store, remember this step MUST be done by an administrators access, otherwise you will get an error about (Keystore not found etc):
certmgr.exe -add NewhexTest.cer -s -r localMachine root
This should add into your keystore, Once done, you can then:
8) Go into your device manager, and add your new driver, you would get a warning but will be accepted and installed without the need to reboot with a forced (Don't check cert type account).
I tried this already and it works on Windows 10 and Windows 8 pro versions.
Kind Regards
Heider Sati
You are supposed to use inf2cat, not makecat, because you have an INF file.
You should work on addressing those warnings from inf2cat by fixing your INF file. Here is my INF file that uses usbser.sys and doesn't cause any warnings: https://gist.github.com/3647208
I was able to fix my INF file thanks to the advice from chinzei in the first post of this thread: http://www.microchip.com/forums/m488342-print.aspx
If you continue to have trouble, please edit your question to include the source of your INF file, or at least a link to the source.
I encounter the same problem and was able to install my driver with a TEST certificate using the instructions provided here:
http://msdn.microsoft.com/en-us/windows/hardware/gg487328.aspx

Resources