This problem can be solved by either disabling lockdown on the client or adding a registry key on the client for allowhotkey.
—————————
Error number 2320
—————————
Citrix online plug-in Configuration Manager: No value could be found for (AllowHotkey) that satisfies all lockdown requirements. The lockdown requirements in force may be conflicting.
—————————
OK
—————————
option 1 (disable lockdown)
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions
Enablelockdown change to 0
option 2 add reg key for AllowHotkey with empty value
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Client Engine\Hot Keys
“AllowHotkey”=””
EDIT: I read somewhere that it needs 50MB of free space on the partition. Maybe you can first assign a drive letter using disk management and see if you can free up some space.
I had this “Something went wrong” & “unable to install on partition” error when I tried to upgrade a Laptop with Windows 7 Home Premium 64-bit installed. This laptop is from late 2011, and had Windows 7 pre-installed by the manufacturer.
This cryptic error, in my case, just meant that the hidden reserved system partition that Windows 7 creates on install was too small/full for Windows 10.
In earlier versions of Windows 7 this partition would be created with a size of 100MB. In Windows 8 I mostly see this partition with a size of 400MB.
So what to do? Expand this hidden system partition from 100MB to at least 400MB. To be safe for the future I expanded it to 800MB.
Now this is not something you can do from within Windows, because the C partition will have to shrink AND move to the right to make room to expand the system partition.
First select the C partition and shrink by 700MB and move it to the right so that the free space comes available in between the small SYSTEM partition and the C partition. Then next select the SYSTEM partition and expand by 700MB until the free space is gone.
Now click the execute button, the software will tell you it must reboot to execute these actions.
Go ahead reboot, and then wait for some time (could take up to hours on big and slower drives) for the software to finish. You get a nice progress bar. For me it took 10minutes on an SSD.
When it’s finished it will boot Windows and you can check in Disk Manager if everything looks good. You can then uninstall or keep the software and start your Windows 10 Upgrade again.
How to display the Windows 10 upgrade icon if it is not visible:
I have seen the windows 10 upgrade notification appear on Windows 7 SP1 & 8.1 computer just fine.
Let me start out by saying this: “When the computer is joined to an active directory domain the icon will not show”. Not matter how hard you try to manually get it started by triggering the tasks or runing the GWX.EXE or GWXUX.EXE applications. It won’t work (for now?) on domain joined computers. Not even if you logoff and logon using a local administrator account.
When you remove your active Directory domain membership and put the computer in a workgroup you will see the icon after the reboot. You can then make your reservation, but I don’t think it will actually download the upgrade on July 29th if the computer is joined to the domain again, not sure about that.
If you’re a home user not connected to an active directory domain there are some things to check:
– You need to be on Windows 7 SP1 or Windows 8.1 Update1
– You need to have the KB3035583 update installed
If you still have trouble getting the icon you can try the BAT file created by a Microsoft Answers forum moderator. https://www.dropbox.com/s/0u0au9xgy6ss18p/win10fix_full.zip?dl=0 (no need to register at dropbox just skip,
download and unzip the BAT file in the C:\TEMP directory (create dir if needed).
Open a CMD with administrative rights.. (right click on CMD icon in start menu and choose Run as Administrator)
CD c:\TEMP
win10fix_full.bat
Follow the instructions …
The FreeRadius.net package built for windows uses the XYZservice.exe wrapper tool to start a normal application as a service. However on Windows 2008 and higher the service starts but RADIUS is not listening on the configured ports. You can check if it is listening with netstat. netstat -an | findstr 1812
The Debug mode of FreeRadius.net (using the provided batch file) however works fine. It seems the built radiusd.exe will not start with the default options on Windows 2008 and higher. You can check this by manually starting from a command prompt: C:\FreeRADIUS.net\bin\radiusd.exe -f -d C:/FreeRADIUS.net/etc/raddb
So that is the reason why the service doesn’t start.
Solution: COnfigure the XYZservice to start the application with the debug parameters.
Edit C:\FreeRADIUS.net\bin\XYZservice.ini
change: CommandLine = C:\FreeRADIUS.net\bin\radiusd.exe -d C:/FreeRADIUS.net/etc/raddb -AX
Now if you start the FreeRadius.net service and check with netstat you will see the RADIUSD.exe listening
The address of the remote RADIUS server x.x.x.x in remote RADIUS server group yyyyy Resolves to local address x.x.x.x.
The address will be ignored.
Use case scenario: You want to forward RADIUS requests incoming on the server to some software, possibly for setting up OTP authentication.
My scenario: Extra security for PPTP vpn tunnel to Windows server with RAS (Routing and Remote Access) by using VASCO Identikey OTP (One-Time-Passkey) software (the same applies for other software such as RSAid). Normally the recommended setup is using two servers, one for the RAS connection and one with the VASCO Identikey middleware software on it. When you deploy like this you will not face the problem I’m about to describe. However if you have only 1 Windows server at your disposal and you install the VASCO Identikey software on the same server as the RAS and NPS (Network Policy Server) role you will run in to this problem.
Problem description: You have configured RAS correctly for PPTP MSCHAP v2 connections. In NPS you have configured a connection policy to forward the RADIUS requests (authentication and accounting) to a remote RADIUS server group. The authentication fails, VASCO audit viewer does not show any attempt to authenticate to the VASCO Identikey Radius server. In the eventviewer application log there is an event ID 25 with the following error: The address of the remote RADIUS server x.x.x.x in remote RADIUS server group yyyyy Resolves to local address x.x.x.x.
The problem is that NPS cannot forward RADIUS requests to the same IP address as itself. Even if the software is listening on another port, or you configure 2 IP addresses on the same network card. NPS insists that the IP address of the remote RADIUS server is the same as it’s own IP address and ignores your configuration to forward the RADIUS requests.
The solution is to use the loopback IP address range. For example 127.0.0.2. Unfortunately VASCO Identikey is licensed on IP address and as such you can’t change it to listen to the loopback IP address without also requesting a new license. I have not tried this, so even with the new license I’m not sure VASCO Identikey will listen on loopback IP address. Maybe other OTP software can do this, check with your vendor or manual.
What can you do? Use a RADIUS proxy to sit between the NPS and VASCO Identikey. If you have a linux server around you can use opensource FreeRadius software on that linux box to proxy the RADIUS requests between RAS/NPS and VASCO Identikey.
If like me you had nothing but this 1 windows server, you can use the FreeRadius.net software, this is a prebuilt binary of the opensource FreeRadius software made for windows versions. The software is quite old and not updated but it still seems to work for our simple setup.
I have installed the FreeRadius.net software in C:\FreeRadius.net
I have configured it to accept RADIUS requests on interface 127.0.0.2 port 11812 and forward them to a RADIUS server on IP x.x.x.x on port 18120 (I changed the default RADIUS ports for VASCO and FreeRadius to avoid conflicts with NPS/RAS).
configuration file c:\FreeRadius.net\etc\raddb\clients.conf
I have put all the default things in comment (#) and add client 127.0.0.2 {
secret = testing123
shortname = localhost2
}
configuration file c:\FreeRadius.net\etc\raddb\radiusd.conf
I have put the default listen directive in comment (#) but you must leave the bind = * line and add listen {
ipaddr = 127.0.0.2
port = 11812
type = auth
}
listen {
ipaddr = 127.0.0.2
port = 11813
type = acct
}
configuration file c:\FreeRadius.net\etc\raddb\proxy.conf
In this file I configured both the NULL realm for plain usernames and the DEFAULT realm for all others to forward to VASCO Identikey wich I have listening on the port 18120 & 18130 (auth & acct). # This realm is for requests which don't have an explicit realm
# prefix or suffix. User names like "bob" will match this one.
#
realm NULL {
type = radius
authhost = 10.x.y.z:18120
accthost = 10.x.y.z:18130
secret = testing123
}
#
# This realm is for ALL OTHER requests.
#
realm DEFAULT {
type = radius
authhost = 10.x.y.z:18120
accthost = 10.x.y.z:18130
secret = testing123
}
You can now start the FreeRadius.net in debug mode, using the supplied batch file you can test your configuration.
Below I will attach screenshots of my configuration for NPS, RAS and VASCO.
This is a very strange problem I came across on a windows 7 Embedded thin client. I don’t quite understand what went wrong but I’ll give you a detailed description.
CASE:
The user has a thin client with Windows 7 Embedded that’s been entered in to the Active Directory domain. On the public desktop of the thin client there is a RDP file to connect to a Remote Desktop Server (a.k.a. Terminal Server). The user logs on to the thin client using their AD credentials. The user was able to log on to the server using the RDP file without problems until today.
SYMPTOMS:
– User can’t log on to the Remote Desktop Server, the error received is:
The connection was denied because the user account is not authorized for remote login
TROUBLESHOOTING:
Normally this just means that the user is not a member of the “Remote Desktop Users” local group on the server.
– I verified the user was a member of the correct groups to log on to the server.
– I then tried to log on the server with the same credentials from a different workstation. This worked without a problem. Which led me to conclude at the server-side everything was OK.
– On the troublesome workstation (thin client with WIN 7 E in my case) I launched remote desktop with the “Run As Administrator” option and supplied credentials for an admin account. I tried to connect to the Remote Desktop server using the credentials of the troublesome user account. This worked without a problem.
– I tried again without the run as, and it failed again with the same error.
This led me to my conclusion that something was very wrong with the user profile on the workstation for this domain user.
SOLUTION:
I decided to delete the user profile on the local workstation since nothing is stored in it (they don’t work locally). However when I opened Explorer and went to see in “C:\Users” I saw 2 identical folders with the same name (the username of the troublesome user). It seems there were 2 identical profile folders. I didn’t think it was possible for 2 folders to have the same name.
I deleted both folders!
I then opened REGEDIT and went to HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\PROFILELIST
I saw multiple user SID’s and checked them all. To my surprise there were 2 different user SID’s that both had a value c:\users\problem.username underneath it. So 2 different user SID’s for the same username. I thought that was impossible. I deleted both registry keys.
After deleting the profiles and the keys I logged back in with the user and profile was recreated and the remote desktop worked perfectly.
So it seems that the remote desktop client was sending the wrong SID to the server and that was the reason for the unauthorized error message.
Recently I came across an issue with a virtual machine that was deployed from a template. After the newly created virtual machine was booted up it seemed that the generalization did not fully complete. The password was not changed and some other minor things were not as it should have been after full customization runs.
We then saw that the VM kept saying “VMware image customization in progress” on every reboot right before windows boots. If you already have configured and/or are using the VM and don’t want to start over, here’s what you can do.
Open regedit and find the key:
HKLM\SOFTWARE\VMWare,Inc.\Guest Cutomization\
or on a 64-bit system:
HKLM\SOFTWARE\Wow6432Node\VMWare,Inc.\Guest Cutomization\
Change the value for “CustomizationInProgress” to “0”.
Then navigate to the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
Change the value for “BootExecute” to the default of “autocheck autochk *”, you should just delete the “sysprepDecryptor.exe” part and the enters after it. Be careful or your system won’t boot.
You should probably check your SID and see if it’s unique, to make sure the customization did indeed change this. Altough duplicate SID’s should be not a real problem (according to Microsoft), don’t do it on your servers! http://technet.microsoft.com/en-us/sysinternals/bb897417.aspx
PS: In my case the customization failed because sysprep had already been run 3 times (template was cloned from previous deployed machine) and apparently you can only do it 3 times unless you add the special option not to rearm the licensing state (which vmware doesn’t add when customizing).
PS2: If you manually did sysprep but got stuck because with error
A fatal error occurred while trying to sysprep the machine
reboot and using F8 choose repair computer, choose keyboard, type password and choose command prompt. Find your correct drive could be C or D or higher (depends on reserved partitions), and execute the BAT file. Rearm state will be wiped, after reboot you will see not genuine but you can rearm again 3 times now.
My case:
1x Windows 2008 Small Business Server (named: SBS2008)
1x Windows 2008 R2 standard on off-site location (named: TS2008) BACKUP DOMAIN CONTROLLER & GC
Connection between the 2 servers was lost for nearly 3 months.
Replication would only work from SBS2008 to TS2008 but not from TS2008 to SBS2008.
I couldn’t view the shares on \\SBS2008 from the console on TS2008, i received the error “The target principal name is incorrect”. On SBS2008 I could view the shares on TS2008.
In the eventlog there were errors:
The Knowledge Consistency Checker (KCC) was unable to form a complete spanning tree network topology. As a result, the following list of sites cannot be reached from the local site.
The Knowledge Consistency Checker (KCC) has detected problems with the following directory partition.
Directory partition:
DC=domain,DC=local
There is insufficient site connectivity information for the KCC to create a spanning tree replication topology. Or, one or more directory servers with this directory partition are unable to replicate the directory partition information. This is probably due to inaccessible directory servers.
All directory servers in the following site that can replicate the directory partition over this transport are currently unavailable.
The File Replication Service is having trouble enabling replication from SBS2008 to TS2008 for c:\windows\sysvol\domain using the DNS name SBS2008.domein.local. FRS will keep retrying.
Following are some of the reasons you would see this warning.
The session setup from the computer SBS2008 failed to authenticate. The name(s) of the account(s) referenced in the security database is SBS2008$. The following error occurred:
Access is denied.
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server sbs2008$. The target name used was E3514xx-xxxxxxxxxxxxxxx/yyyyyyyyyyyyyyy/domain.local@domain.local. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please …
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server sbs2008$. The target name used was DNS/sbs2008.domain.local. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please …
Demote and the promote for TS2008 would not work without forcing and doing a lot of NTDS cleanup on the PDC. So this was my last resort.
1st reboot -> did not work.
Doing a lot of searching and looking up the SPN for SBS2008 on both DC’s did not show any differences.
I had to disable the KDC (Kerberos Key Distribution Center) service on TS2008 and then reboot.
Immediately after reboot I noticed I could browse the shares on the SBS2008 without error.
This is because TS2008 was no longer supplied Kerberos tickets itself but requesting them from SBS2008.
Now I opened an elevated command prompt and forced a sync of all replica partitions and triggered the KCC checker.
repadmin /syncall /ade
repadmin /kcc
To check the replication backlog queue use:
repadmin /queue
After replication was succesful I put the KDC service back to automatic and started it. Problem solved.
If you can’t get replication working yet, you’ll need these extra steps.
klist /purge
netdom resetpwd /server:sbs2008 /userd:domain\Administrator /passwordd:* (the * will make it prompt for password).
Also you might need to check your DNS settings and put the IP adres of SBS2008 as primary DNS IP on the NIC of TS2008.
Change the system settings to use a . instead (configuration panel, region and local settings, more settings, number).
For existing files, use search and replace to delete spaces. If still left justified multiply all with the number 1 using paste special, see link below.
Does not work for regular standalone Adobe X problems, only when installed (and activated) as part of CS6 suite, and stops to work after 30 days.
1) Download: http://helpx.adobe.com/creative-suite/kb/acrobat-failed-launch-30-days/_jcr_content/main-pars/download/file.res/Acrofix.zip
2) Unzip to a convenient location
3) Open a command prompt as administrator (in start menu search for cmd and right click run as administrator)
4) go to the location where you unzipped
cd c:\temp\adobefix\
5) Execute the executable
Acrofix.exe
6) Exit Code: 0 means succesfully patched!
7) Try Adobe X Pro again.
