Im trying to allow another computer in the same network so acces a server I have local on my computer.
As far as I know, this should be administrated in Componentservices (accesing it by running dcomcnfg.exe). I then rightclick on My Computer and click on the Properties option. Then i click on the tab called Standardproperties and then I check "Activate distributed COM on this computer".
Then I go to COM-safety and click on EDIT. But Distrubuted COM is not in that list for me to administer.
What am I missing?
Related
We just virtualized a Windows server in Azure and everything in working fine on Client side, but we are not being able to solve the indexing search problem.
When you have a local drive, Windows can index the path and searches works fine using Windows menu/search box in task bar. But for shared drives it seems to fail.
In Windows Explorer the search pretends to work, but it takes forever to find a file or folder. And sometimes it just won't move anywhere. So it is not an option for users since them are used to search using menu bar.
We have tried to change drive properties in Right button to Shared Driver > "Allow files on this drive to have contents indexed in addition to file properties, but it was already enabled.
When we try to disable it, it prompts an error saying that the user doesn't have permission to do it, but it does anyway. And when we try to re-enable, the message prompts again, but it is enabled with no problem at all. But once again, nothing changes and Initial Menu Search just won't work.
Does anyone knows if there is a solution for that?
For me it seems to be an server setup since I see that permission error, but, as far as I know, if the shared driver is already mounted, I can't see a reason why Windows can't index it.
Ps.1: In the shared drive security tab, the System has full permissions.
Ps.2: If there is a solution for this, is that possible to solve it on the Windows server Side so we won't need to access client by client to change it manually?
enter image description here
Please check the following setting and see.
1.First thing is to check network location is being indexed. open File Explorer right-click on the mapped network drive that you need to index, then select the Properties and Make sure that, the Allow Files on this Drive to Have Contents Indexed checkbox is selected.
You have already done this step
2.try to check the search options for network drive in file explorer, go to view tab>>click on Options Icon and choose the change folder and search option menu it will open the folder options dialog box and select search tab and make sure first option is not selected
3.check server side Indexing
4.we need to make sure search service needs to be running.
Open services.msc check for the wndows search service and try to restart the service.
5.Go to Settings on the Windows 10 desktop, then click on Search, followed by Searching Windows scroll down and try to run the indexer troubleshooter
Reference https://learn.microsoft.com/en-us/troubleshoot/windows-client/shell-experience/fix-problems-in-windows-search
I'm trying to set up the IIS so I can access my local web application project at dev.example.com. I have the physcical path set to the root of my web app, and the binding as shown in the picture below.
I have added this to the hosts file
But when trying to access it in chrome it just hangs forever.
Is there something I'm missing?
I had to set the permissions of my application pool identity
ApplicationPoolIdentity is actually the best practice to use in IIS7. It is a dynamically created, unprivelaged account. To add file system security for a particular application pool see IIS.net's "Application Pool Identities". The quick version:
If you application pool is named "DefaultAppPool" (just replace this text below if it is named differently)
Open Windows Explorer
Select a file or directory.
Right click the file and select "Properties"
Select the "Security" tab
Click the "Edit" and then "Add" button
Click the "Locations" button and make sure you select the local machine. (Not the Windows domain if the server belongs to one.)
Enter "IIS AppPool\DefaultAppPool" in the "Enter the object names to select:" text box. (Don't forget to change "DefaultAppPool" here to whatever you named your application pool.)
Click the "Check Names" button and click "OK".
I found the answer here
IIS7 Permissions Overview - ApplicationPoolIdentity
I have been using a script forever that uses the windows command line FTP to upload files to a third-party server. (I'm using Windows 7.) Third party recently got a new server and now I can still connect but I can't issue any commands without the connection hanging. I can't even do ls much less a put. It hangs on "Opening data connection for...." After much research I've narrowed it down to their new server not being configured to allow "active mode" FTP connections. I can't configure their server for them, and at this point I'm not sure how competent the server manager is. So I want to know what steps I can tell them to do to configure the server to allow "active mode" FTP connections. I assume their using a windows 7 machine. What do I need to tell them?
Follow this:
Control Panel -> Internet Options -> Advanced tab
Scroll down until you find a checkbox labeled "Use Passive FTP".
Uncheck it.
I have just set up a Guest Windows 2008 R2 Standard Edition 64bit (VirtualBox on Windows 7 64 bit host) for some testing.
I have found that while "inside" the remote desktop environment (i.e. I remote onto the guest ip from the host) that copy and paste does not work. When I say "does not work" let me be explicit.
Assume I am logged onto the Win2008 machine via RDC
Nothing is in the copy/paste buffer. I can mouse click some text and then rclick copy. I can then right click and click "paste" but nothing happens. I can see the "choice" is enabled to paste bu nothing happens. The caret stays put.
CTRL+C / CTRL-V / CTRL-X does not work in RDC land
I am not talking about going in-between copy/paste RDC land/host land.
HERE is the double whammy: when I do the above it then "infects" my host pc so that copy paste is unavailable there too. if PRT SCR doesn't work any more.
I have tried:
restarting the guest os and host os
in group policy editor I have disabled "do not allow clip board redirection" ( I can't give you the full path to this copy/paste just broke again)
I have made sure that in RDC "options" for local resources include clipboard.
NB: if I don't touch RDC at all and log into the guest OS via the console copy paste works perfectly
Kill the rdpclip.exe process using the Task Manager. Then, create a new process named rdpclip.exe. This will solve your problem.
Follow these steps in Remote Machine.
Stop the rdpclip process
Open Task Manager.
Go to process tab and find rdpclip
Choose rdpclip and End that task.
Start rdpclip.exe
Go to start menu and open Run command
Open rdpclip.exe and click Ok button.
Copy paste should work now.
it appears this is a flaw with VirtualBox
these posts covers it
https://forums.virtualbox.org/viewtopic.php?f=6&t=44498 (read the last post)
https://github.com/FreeRDP/FreeRDP/issues/230
(In VirtualBox) SETTINGS->GENERAL->[Advanced]->Shared Clipboard {disabled}
There are multiple things to check.
Restarting rdpclip.exe is a worthy try if the copy/paste fails sporadically, meaning we might on a process in a previous session.
On the client side, we check the RDP Options. Click on the Show Options button in the bottom, pick the third tab Local Resources. Make sure Clipboard is checked.
On the remote server side, we want to check Remote Desktop Session Host Configuration (Win Server 2008+).
Double click the connection to open its Properties window.
In the tab named Client Settings, Make sure Clipboard is not disabled.
We need to log off from the remote desktop.
Workaround
Use an online shared text box like this one:
https://pastebin.com/
Have to test a c# application from client that is to work on a machine that has FIPS enbaled
First, be aware of what actually happens when you enforce FIPS140-2 complient encryption within Windows. Details are at http://technet.microsoft.com/en-us/library/cc750357.aspx. However, the main 'gotcha' (old SSL website's don't work in IE anymore) is detailed in the article linked below.
The official instructions to enable FIPS 140-2 complience are at http://support.microsoft.com/kb/811833, but can be summarised as follows:
Using an account that has administrative credentials, log on to the computer.
Click Start, click Run, type gpedit.msc, and then press ENTER.
In the Local Group Policy Editor, under the Computer Configuration
node, double-click Windows Settings, and then double-click Security
Settings.
Under the Security Settings node, double-click Local Policies, and
then click Security Options.
In the details pane, double-click System cryptography: Use
FIPS-compliant algorithms for encryption, hashing, and signing.
In the System cryptography: Use FIPS-compliant algorithms for
encryption, hashing, and signing dialog box, click Enabled, and then
click OK to close the dialog box.
Close the Local Group Policy Editor.
If you wish to do this manually, you can also simply change the registry key HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled to 1
Finally, to repeat, it is very important that you read through the documentation before you enable this - it changes cryptography system wide, including how the file system (both EFS and Bitlocker) and network (IE, Remote Desktop and the main cryptographic libraries) are allowed to encrypt, as well as if you allowed to recover lost encryption keys.
As an alternative, for Windows 7 users (with admin rights), this is one of the "Network Properties". Step by step:
click on the "Network" icon on task bar.
right click > Properties on the specific Network connection
switch to the "Security" tab.
click on "Advanced Settings" button.
click the checkbox labeled "Enable Federal Information Processing Standards (FIPS) compliance for this network.
Also, have in mind:
Recommended reading: http://technet.microsoft.com/en-us/magazine/ff847520.aspx
This setting sepends on what you have selected as "Security Type" on the Security Tab
Your wireless network adapter card might be doing this encryption in hardware already. This checkbox will switch from that to rather performing AES encryption in software.